When to pursue security certification

Someone has told you that you need SOC2. It was probably a prospective customer during a sales call, though it could have been an investor during diligence, your new security hire, or a compliance consultant who’d quite like the engagement. They’re likely right that you need it, or something like it, eventually.

The question isn’t whether but when, which certification, and how to do it without building something that becomes more expensive to maintain than it was to create.

Most founders get at least one of those three wrong, and the result is either a certification pursued too early that describes an organisation which no longer exists by the time the audit completes, or a panicked scramble under deal pressure that costs twice what it should and produces a programme nobody can sustain.

Both are avoidable if you treat certification as what it actually is: a business decision, not a security milestone.

Certification is a business decision

Compliance and security aren’t the same thing: you can be certified and insecure, and you can be secure and uncertified. Certification exists to satisfy external parties, and the decision to pursue it should be driven by which external parties are asking for what.

The triggers are usually one or more of these:

Customers require it. Enterprise buyers increasingly expect SOC2 or ISO 27001 as a condition of procurement. If your pipeline is full of companies that won’t sign without a SOC2 report, you have a clear business case with a number attached to it.

Regulators expect it. If you’re in financial services, healthcare, or any sector handling consumer data in the UK or EU, regulatory expectations create a baseline. This might mean a specific certification or demonstrable compliance with a framework.

Investors value it. Series B and C investors increasingly look at security maturity as part of due diligence. Certification is a shorthand signal that you’ve done the work, even if the investors themselves don’t read the audit report in detail.

Payments providers require it. If you process card payments, PCI DSS compliance isn’t optional. Your payments provider or acquiring bank mandates it, and the scope depends on how you handle card data. This one tends to catch B2C companies off guard because it’s not driven by customer demand but by your technical and vendor choices.

PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements for any organisation that stores, processes, or transmits cardholder data. For most startups, this means completing a Self-Assessment Questionnaire (SAQ) through your payments provider. The scope varies significantly depending on how you handle card data. If you’re using a third-party processor like Klarna, Mollie, or Stripe and never touch card numbers directly, your SAQ is straightforward. If you’re handling card data in your own environment, the requirements escalate considerably. Getting this wrong can result in fines, increased processing fees, or losing the ability to accept card payments entirely.

If none of these triggers apply to you today, you probably don’t need certification yet. That doesn’t mean you shouldn’t be building good security practices (knowing what you’re protecting, what risks you carry, and what you’re doing about them is valuable regardless), but certification without a clear business driver is spending money to solve a problem that doesn’t exist yet.

The timing question

The right time to start certification work is typically 6-9 months before you need it. If enterprise customers are entering your pipeline, start now. If they’re 12 months away, use that time to get your foundations right so certification documents what you already do rather than forcing you to build from scratch under pressure.

The Potemkin Village problem

Here’s what nobody tells you about early-stage SOC2: it works, it gets deals done, and it’s also a bit of a facade that describes a moment in time rather than a sustainable security programme.

A SOC2 for a 10-person company with a four-person engineering team is a real certification. The auditor assessed your controls, found evidence they exist, and issued a report that customers accept and that closes deals.

But the environment it describes is very small and very simple: your access controls are manageable because everyone knows everyone, your change management works because three people deploy to production, and your vendor oversight is straightforward because you’re using fifteen tools, not fifty. The controls are real, but they’re operating in conditions that make compliance relatively easy.

This is fine; it gets deals done and it’s the right call at that stage. Nobody should feel guilty about this. You built something that satisfied a real business requirement, and the auditor confirmed it met the standard. The fact that the standard is designed to be passable is not your problem to solve.

The problem is year two: by the time your Type II audit comes around, you may have grown from 10 to 40 people. New teams, new systems, new vendors, new engineers who joined after the controls were documented. The processes that worked when everyone sat in the same room may not work across three engineering teams in two time zones. The controls that were easy to evidence when one person managed access are now likely scattered across multiple systems with no clear owner.

A SOC2 Type I report confirms that your controls exist and are suitably designed at a specific point in time. A Type II report goes further: it confirms that those controls operated effectively over a period, usually 6-12 months. Type I gets you started. Type II is what enterprise customers want to see, and it’s where the real work begins because you need to demonstrate consistent operation, not just design.

The best time to pursue certification is when you can shape it around your business and on your own terms.

The founders who anticipated this shaped their programme from the start to accommodate growth, and put in the time each month to keep things adjusted so there were no surprises later. The founders who didn’t are facing a choice between an expensive urgent retrofit and an audit that reveals gaps they weren’t expecting.

When a customer gives you 90 days

If you’re under deal pressure to certify quickly, negotiate. Ask for the contract to require certification in progress during the first renewal period rather than completed before signing. Most enterprise buyers will accept this if you can demonstrate a credible plan and timeline, and it gives you the space to build something sustainable rather than something that just passes the first audit.

Shape it before it shapes you

The default path for most startups is to hire a compliance consultant who implements their standard playbook. You get policies based on templates, a control framework mapped to the certification requirements, and a programme that’s technically correct but practically disconnected from how your company actually operates and alien to how it will operate in future.

This isn’t entirely the consultant’s fault, since they’re building what you asked for: a programme that passes an audit. The problem is that nobody told them what your business actually needs from compliance, and their budget probably allows for little substantive customisation.

The companies that manage certification well do something different. They start with their own understanding of what they’re protecting, what risks they carry, and what’s proportionate at their stage, then work with their compliance partner to build a programme that reflects actual practices, actual risks, and actual growth trajectory.

The difference shows up in two ways:

The programme is cheaper to maintain. Controls that match how your team actually works don’t require constant workarounds, and policies that describe real practices don’t need quarterly rewrites. Evidence collection is straightforward because you’re documenting what happens naturally rather than manufacturing evidence for processes nobody follows.

The programme scales. If your controls are designed with growth in mind, your year-two audit isn’t a crisis. New team members can follow existing processes and new systems fit into the existing framework, so the programme grows with the company rather than breaking under the weight of it.

The cargo cult trap

Don’t accept every control your compliance consultant suggests without questioning it. Ask: does this control address a real risk for our business at our current stage? Can we operate it more simply? If the answers are no, push back. A lean programme that covers your actual risks is more sustainable and more defensible than a comprehensive one full of controls that exist on paper and nowhere else.

The practical cost difference between a well-shaped programme and a generic one is significant. I’ve seen companies spend £100-150k on certification programmes that could have been done for a quarter of that if someone had asked the right questions at the start. The excess isn’t in audit fees; it’s in unnecessary controls, policy documents nobody reads, and tools purchased to evidence compliance with requirements that don’t apply to your business.

Which certification, and when

The right certification depends on who’s asking and where they are. Here’s the practical picture for European startups:

SOC2 is increasingly the cost of entry for B2B companies selling to enterprise customers, particularly if those customers include US companies or their European subsidiaries. It’s well understood by procurement teams, it’s what most enterprise security questionnaires reference, and your competitors probably have or are pursuing it. If you’re B2B and heading upmarket, SOC2 is likely your first certification. Budget 4-9 months and £15-60k depending on complexity, remediation requirements, and whether your foundations are already in place.

SOC2 is built around five trust service criteria: security (always required), availability, processing integrity, confidentiality, and privacy. You choose which criteria to include based on what your customers care about. Most startups start with security alone or security plus availability. If you handle significant personal data, scoping in the privacy criterion can address GDPR-related customer questions within the same audit. The choice of criteria is itself a business decision.

ISO 27001 carries more weight in European markets and regulated industries. It’s a management system certification rather than a controls report, meaning it focuses on how you manage information security rather than a specific set of controls. It’s more comprehensive than SOC2 and takes longer to achieve, but for companies operating primarily in European enterprise markets it may be more valuable. Some companies pursue both, which is achievable since there’s significant overlap, but doing them in parallel at an early stage is usually overkill.

Cyber Essentials is the UK government-backed baseline certification. It’s cheap, covers five fundamental technical controls, and is required for UK government contracts involving sensitive data. It’s a useful starting point and a signal of basic hygiene, but it won’t satisfy enterprise customers demanding SOC2 or ISO 27001. Think of it as a foundation your bigger certifications build on.

Cyber Essentials has two tiers. The basic certification is a self-assessment against five technical controls: firewalls, secure configuration, security updates, access control, and malware protection. Cyber Essentials Plus adds independent technical verification. It’s government-backed, relatively inexpensive, and increasingly expected in UK supply chains, with major banks now pushing it as a procurement requirement for their suppliers. It’s a good discipline exercise even if your customers aren’t asking for it, but it covers a narrow scope compared to SOC2 or ISO 27001.

PCI DSS applies if you handle payment card data, and it’s not voluntary. The scope depends entirely on how you process payments. If you’re using a hosted payment page or tokenisation through a provider like Stripe, your self-assessment is manageable. If card data touches your own systems, the requirements escalate quickly. The mistake B2C companies often make is not understanding their PCI scope early enough, because the architectural choices you make now determine how painful this becomes later.

GDPR certification schemes are emerging at EU and national level, with Europrivacy as the first EDPB-approved European Data Protection Seal and the ICO developing UK-specific schemes. In practice, these aren’t yet a common market requirement for startups. Your GDPR obligations are real and non-negotiable if you handle EU consumer data, but demonstrating compliance through your existing security programme and documentation is more practical than pursuing a dedicated certification right now. This will probably change over the next few years, particularly if data protection is core to your value proposition. If you’re pursuing SOC2, consider scoping in the privacy criterion to cover some of this ground.

A practical sequence

For most European startups scaling into enterprise sales: Cyber Essentials first as a hygiene baseline, SOC2 Type I when your pipeline demands it, SOC2 Type II twelve months later, and ISO 27001 when your European enterprise customers or regulatory environment requires it. PCI DSS runs on its own track, driven by your payments infrastructure. Don’t try to do everything at once, and don’t start any of them until you have a clear business driver.

The certification that matters most

The certification that matters most is the one that removes friction from your most important external relationships right now. Not the one that looks best on your website, not the one your compliance consultant recommends, and not the one your competitor just announced on LinkedIn.

If your biggest deals are stalling on security reviews, that’s your signal; if your regulator is asking questions you can’t answer, or investors are flagging security as a risk factor, those are your signals too.

Start there and shape the programme around your actual business. Keep it lean enough to maintain as you grow, and remember that the certificate is a means to an end: it exists to build trust with the people who need to see it. Security itself is something your organisation does, not something you buy from an auditor.