Cyber Essentials, SOC 2, DORA: A UK C-Suite Decoder for Which Certification Actually Matters

Key Takeaways

• Two real companies, Arcata Cloud and Copp Clark, cleared two different compliance bars, SOC 2 and DORA, under real commercial pressure, and both stories are genuinely instructive for a UK C-suite, provided the specific claims are read precisely rather than treated as interchangeable proof of “being secure.”
• Arcata Cloud passed SOC 2 Type 1 on its first attempt in four weeks. That’s a real, well-executed result, but Type 1 tests whether controls are properly designed at a single point in time, not whether they hold up under sustained operation, which is what SOC 2 Type 2 actually tests over a three-to-twelve-month observation window. Sophisticated enterprise buyers generally treat Type 1 as a credible first step, not the final answer.
• Copp Clark, a Canadian reference-data provider, is described in its own case study as having “found itself classified as an ICT third-party service provider” under the EU’s DORA regulation. That’s a real and common pattern, being pulled into a financial customer’s own compliance register, but it’s a materially different, lighter designation than being named a formally-designated “Critical ICT Third-Party Provider” by EU regulators, a status held by only 19 firms globally as of the first official list published in November 2025.
• Rigour, roughly ranked for a UK C-suite: Cyber Essentials (self-assessed, five baseline controls) sits well below Cyber Essentials Plus (independently tested), which sits below SOC 2 Type 1 (independently audited design), which sits below SOC 2 Type 2 (independently audited operation over time), with DORA sitting apart from all of them as a binding EU regulation rather than a certification at all.
• None of that undermines what either company achieved. It means a board should ask a more specific question than “are they certified”: which specific standard, which tier of that standard, and tested over what period.

Compliance certifications and regulatory labels tend to get treated in boardrooms as a single signal: certified or not, compliant or not. That flattens genuinely useful distinctions a UK C-suite should actually understand, both when evaluating its own posture and when reading a vendor’s claims. Two real case studies, one an enterprise SOC 2 audit under a hard launch deadline, one a Canadian company’s brush with EU financial regulation, are a useful way into what those distinctions actually are.

Arcata Cloud: a real first-attempt pass, of a specific, faster kind of audit

Arcata Cloud was four weeks from a public launch with a non-negotiable deadline: an enterprise customer had made SOC 2 Type 1 compliance a contractual condition of signing, and the audit had to be booked and passed inside that window. The company’s security posture had grown organically as the product was built, which meant nobody had a clear picture of where the actual gaps were. Hashorn ran a two-phase engagement, starting with comprehensive threat modelling using STRIDE analysis, a real, established methodology developed at Microsoft in 1999 covering spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege, alongside a full application and infrastructure-as-code audit, then moving into prioritised hardening work. That included migrating secrets into HashiCorp Vault, tightening 213 separate IAM policies, and wiring DevSecOps tooling, Semgrep, Checkov and Trivy, into the pipeline so the same issues couldn’t creep back in unnoticed. “We knew our security posture had grown organically. We didn’t know we had two critical issues we’d been shipping for nine months. Hashorn found them, helped us fix them, and got us through SOC 2 on the first try,” said Priya Iyer, CTO of Arcata Cloud. By the company’s own account, Arcata Cloud launched with zero critical CVEs outstanding, all high and critical findings resolved before the deadline, and passed its SOC 2 audit on the first attempt with zero observations.

That’s a genuinely strong result, and it’s worth being precise about what it actually certifies. SOC 2 Type 1 assesses whether an organisation’s controls are suitably designed at a single point in time; SOC 2 Type 2 assesses whether those same controls actually operated effectively over a sustained observation period, typically three to twelve months. A four-week timeline is plausible and unremarkable for Type 1 specifically, industry sources put typical Type 1 timelines at four to eight weeks, precisely because there’s no observation period to wait out; it’s a design review, not an endurance test. Enterprise procurement teams generally treat a Type 1 report as a credible first step, sufficient to unblock an early deal, but expect a Type 2 report before granting deeper production access or renewing at scale. None of that diminishes what Arcata Cloud did under real time pressure. It means “passed SOC 2 on the first try” is the correct, honest description of a real achievement, and “proven secure over time” is a claim Type 1 doesn’t make, and isn’t designed to.

Copp Clark: a real DORA engagement, with a classification worth reading precisely

Copp Clark, a Canadian company supplying financial institutions with global public holiday, trading hour and close-day data, found itself classified as an ICT third-party service provider under the EU’s DORA regulation because of the European financial businesses it serves. The tricky part wasn’t the regulation itself, it was scoping Copp Clark’s proportional responsibility accurately, so the company didn’t drain its resources on compliance activities that went beyond what its actual role required. Sigma Software ran stakeholder interviews to map Copp Clark’s existing security processes, then performed a gap assessment benchmarked directly against DORA’s requirements for ICT third-party providers, producing a Risk Management Policy, Third-party Management Policy, Business Continuity & Disaster Recovery Plan, and Incident Response Plan, followed by Digital Operational Resilience Testing, scoping a penetration test specifically to Copp Clark’s distributed infrastructure rather than running a blanket, resource-heavy assessment across everything. “It was our pleasure working with the Sigma Software. They provided friendly, professional, and informative support at all times,” said Carol Champ, VP – Operations at Copp Clark Limited. The engagement helped Copp Clark establish a security process aligned with both DORA and ISO 27001, and the company went on to pass third-party regulatory checks requested by its European financial customers.

DORA, which became enforceable across the EU on 17 January 2025, applies to a broad set of EU-regulated financial entities and, separately, to the ICT third-party providers those entities rely on. It’s worth understanding that “ICT third-party provider” status under DORA actually comes in two meaningfully different tiers. The ordinary tier is a classification a financial-services customer effectively assigns to its own vendors as it builds its required DORA Register of Information, a broad, genuinely somewhat ambiguous category at the edges that a company like Copp Clark can be pulled into simply by serving EU financial customers, exactly the pattern this case study describes. The second, formal tier is “Critical ICT Third-Party Provider” status, a designation made directly by the EU’s supervisory authorities, and it is a considerably narrower club: only 19 firms, mostly major cloud and technology providers, were named on the first official list, published in November 2025. The case study’s framing of Copp Clark as having “found itself classified” as an ICT third-party provider is an accurate and defensible description of the ordinary, customer-driven tier. It is not the same claim as formal critical-provider designation by EU regulators, and a board reading a similar case study elsewhere should keep that distinction in mind rather than assume every “DORA classification” story describes the same regulatory weight.

A rigour decoder for the boardroom

Set alongside the UK’s Cyber Essentials scheme, these two case studies map out a useful, honest hierarchy for a C-suite to keep in mind rather than treating every certification or regulatory mention as equivalent proof of security maturity. Cyber Essentials, at its base tier, is a self-assessed questionnaire against five fixed technical controls, externally verified but not independently audited; Cyber Essentials Plus adds genuine independent technical testing on top of the same five controls. SOC 2 goes considerably further, covering not just technical controls but change management, monitoring and alerting, incident response and vendor risk management, evidenced through documented policy and independent audit testing, with Type 1 checking that those controls are properly designed and Type 2 checking that they actually held up in practice over months of real operation. DORA sits apart from all of it: not a certification a company can hold at all, but a binding EU regulation with legal force, covering operational resilience, mandatory incident reporting timelines, a formal register of third-party relationships and, for the largest and most integrated providers, threat-led penetration testing. ISO 27001, the international information security management standard Copp Clark aligned to alongside its DORA work, is a genuinely useful practical foundation for DORA compliance, most compliance advisories treat it as a substantial head start, but it does not by itself satisfy DORA’s more specific obligations around incident-reporting timelines and the Register of Information.

What a UK C-suite should actually ask

Both of these case studies describe real, well-executed work under real constraints, a four-week deadline in Arcata Cloud’s case, a proportionality problem in Copp Clark’s. Neither deserves to be read as more, or less, than what it actually is. The useful discipline for a board, whether assessing its own posture or a vendor’s claims, is to stop accepting “certified” or “compliant” as a single, flat answer and ask three sharper questions instead: which specific standard is being claimed, which tier or type within that standard, Type 1 or Type 2, base Cyber Essentials or Plus, ordinary third-party status or formal critical designation, and tested or observed over what period. Arcata Cloud and Copp Clark both have real, creditable stories to tell. The value of understanding the fine print isn’t doubting either of them. It’s knowing exactly what to ask the next vendor whose case study is less carefully worded.