Most companies run SOC 2 and ISO 27001 one after the other. The reasoning is usually that doing both at once doubles the work, so you get the report your buyers keep asking for first and come back for the certificate when things are calmer.
It is often the wrong call, and the reason is arithmetic rather than ambition. The two standards overlap heavily in what they ask you to actually do. The expensive parts of a compliance programme are evidence collection and remediation, and if you separate the two frameworks by a year you do both of those twice. You also end up with two sets of evidence produced at different times by different people, which tend not to agree with each other in ways an auditor will notice.
This is an account of running both together for a data centre operator in Waterloo, Ontario, from the first assessment through remediation and into audit preparation.
The company
A data centre operator running three physical sites, with the primary production campus in Waterloo. Around twenty people, split roughly half and half between employees and directors on one side and subcontractors on the other.
That split matters more than the headcount does. Compliance frameworks do not care about your employment relationships, they care about who can reach the systems in scope. A subcontractor with production access sits inside the boundary exactly as an employee does, and needs the same onboarding record, the same access review, the same offboarding evidence. The difference is that the artefacts live in different places. An employee has an HR file. A subcontractor has a contract, and whether that contract carries the confidentiality and security obligations you need is a question worth asking early rather than during fieldwork.
Across those sites, three systems are in scope: the datacenter platform itself, an AI compute platform, and a self-hosted email and collaboration stack.
That last one is unusual and it changes the shape of the engagement. Most companies of this size run Google Workspace or Microsoft 365, and in doing so they inherit an enormous amount of security posture from the provider. Mail filtering, malware scanning, authentication, availability, backup, all of it arrives configured and attested by somebody else, and a large share of your evidence becomes a vendor report you can reference. Self-hosting means every one of those controls is yours to operate and yours to evidence. It is a defensible engineering decision and it is more compliance work, and pretending otherwise helps nobody.
Three sites is the detail that changes the engagement. A software company has one logical environment and inherits its physical controls from a cloud provider. Three facilities means physical access control, visitor handling, equipment siting, cabling and environmental monitoring are yours at every one of them, and an auditor will sample across sites rather than trusting that what is true in Waterloo is true elsewhere. Further sites across southwestern Ontario and Quebec enter scope as they reach production, which is a scoping problem before it is a control problem and is dealt with below.
Why both frameworks, and why together
The buyer requirements pointed in two directions at once. North American customers were asking for SOC 2 by name. The ISO certificate carries more weight in other markets and with procurement teams that work from an approved standards list rather than from a report. Picking one and revisiting the question in a year would have meant doing the underlying work twice.
The SOC 2 scope covers three Trust Services Criteria: Security, Availability and Confidentiality.
Availability is doing real work in that list. For a typical SaaS company it is a nice inclusion that makes the report look thorough. For a data centre operator, uptime is the product. Customers are buying the guarantee that the facility and the platform stay up, which means the availability criterion maps onto commitments the business is already making commercially. Confidentiality follows from the customer data moving through the platform.
On the ISO side the target is ISO 27001:2022 including the Climate Action Amendment. That amendment is recent enough that a good deal of readiness material still does not mention it, and plenty of template ISMS documentation predates it entirely. It requires you to consider climate change in your interested-parties analysis and in the determination of relevant requirements. For a business that runs physical facilities with significant power and cooling demands, that is not a paperwork exercise. It touches the risk assessment in ways the certification body will expect to see reflected.
Scoping a boundary that is going to grow
The hardest question in this engagement was not a control. It was the boundary.
An ISMS needs a defined scope, and a SOC 2 needs a system description, and both are documents you will be held to. Write them tightly around today and every new site triggers a scope change, a document revision and a conversation with the certification body. Write them loosely to avoid that and you have committed to evidencing controls at facilities that are not built yet.
The approach that works is to define the boundary by function and criteria rather than by listing addresses. A site enters scope when it reaches production and meets the stated conditions, and the ISMS documentation describes that rule rather than enumerating the sites. New facilities then arrive inside an existing framework rather than triggering a rewrite. It takes longer to draft and saves months later.
Physical security deserves separate mention here because it is where a data centre engagement diverges most from a software one. For a SaaS company, Annex A physical controls are largely inherited from a cloud provider and dispatched with a reference to their report. When you operate the facility, physical access control, visitor handling, equipment siting, cabling security, secure disposal and environmental monitoring are all yours. Those are real controls with real evidence, and they are frequently the ones a first-time candidate has running well in practice but has never documented.
Phase 1: assessment and situation review
The engagement opened at the end of June with a fixed-scope assessment. This is the phase people are most tempted to skip, and the temptation is understandable, because you generally do know roughly where you are weak.
The problem is that roughly is not a scope. It is also not a Statement of Applicability, and it is not a system description. Getting either of those wrong at the start produces one of two outcomes: you do work you never needed to do, or you discover in month three that something sitting in production was never inside the boundary you described, which is the expensive version.
The assessment ran against both frameworks simultaneously, mapping where a single control satisfies both and where the standards genuinely part company. That mapping is the entire argument for running them in parallel, so it is worth being concrete about it.
A large share of ISO 27001 Annex A lines up closely with the SOC 2 common criteria. Access control, change management, supplier relationships, incident management, logging and monitoring, cryptography, secure development, business continuity. Do that work once and design the evidence once, and you have satisfied both. The control does not know which framework is asking.
Where they diverge is where the effort concentrates, and the divergence is not symmetrical.
ISO wants a management system, and that is a genuine addition rather than a rewording. It wants a risk assessment methodology you can show your working for, not just a risk register. It wants a Statement of Applicability that justifies every control you included and every one you left out. It wants internal audit performed by someone sufficiently independent, and management review with evidence that it happened and that decisions came out of it. None of that has a direct SOC 2 equivalent.
SOC 2 Type II, conversely, wants operating effectiveness demonstrated across an observation window, sampled at multiple points. ISO certification approaches the same question differently, through a stage 1 and stage 2 audit and surveillance thereafter. A control that is well designed but has only been running for three weeks is a different problem for each standard, and knowing which one is the binding constraint on your timeline changes how you sequence the work.
Phase 1 delivered its findings and closed at the end of July.
Phase 2: remediation and audit preparation
Findings were delivered and remediation began on the items that were both material and quick, which is the sequencing that keeps a programme moving.
The instinct is to work top down by severity, and it is worth resisting. The better first pass is to clear anything that blocks evidence collection, because a control that is both unremediated and evidence-producing stays invisible until somebody asks for it. If your access review has no owner and no schedule, that is one finding. If it also means you cannot produce a single completed review when the auditor samples the period, it is a finding that has quietly consumed your timeline as well. Fixing the evidence pipeline early means the rest of the remediation produces artefacts as it goes rather than needing a second pass to document it.
Alongside remediation, the introduction that decides how the rest of the programme goes. We placed the client with a firm that is both a licensed CPA firm and an accredited certification body, so the SOC 2 attestation and the ISO 27001 certification run through one organisation rather than two. One engagement letter, one evidence process, one calendar. They were engaged during remediation and a weekly cadence was set.
Bringing them in during remediation rather than after it is deliberate. Scope, sampling approach and what counts as sufficient evidence for a given control are all matters you discuss with an auditor, not instructions you receive from one. A team that first speaks to its auditor when it believes it is ready has given that conversation away, and usually finds out during fieldwork that an artefact it spent three weeks producing is not the artefact that was wanted. A weekly cadence means a disagreement surfaces in week three rather than in the audit.
It also matters that there are two of them. A CPA firm and a certification body have different expectations, different sampling behaviour and different timelines, and where the same control is serving both, it is worth confirming early that the evidence you plan to produce satisfies each. That is a short conversation to have up front and an expensive one to have late.
What we would tell another operator
Define the boundary before anything else, and define it by rule. Which sites, which platforms, which people, and on what condition a new site enters scope. A boundary written as a list of addresses will be rewritten every time you grow.
Map the two standards against each other before doing any control work. The overlap is where the savings are, and you cannot bank them once you have already built two separate programmes.
Treat subcontractors as in scope from day one. If they can reach production they are inside the boundary. Check that their contracts carry the obligations you are about to claim they carry.
Self-hosted infrastructure is more compliance work, not less. Every control a SaaS company inherits from Microsoft or Google is one you now own, operate and evidence yourself.
Physical and environmental controls are real work when you run the facility. They are usually running well and documented badly, which is the cheapest gap to close if you find it early.
Talk to the auditor and the certification body during remediation. Scope and sampling are discussable. That conversation is worth having before you have built everything around an assumption.
If you are weighing the two frameworks and wondering whether to sequence them, our comparison of SOC 2 and ISO 27001 for Canadian companies covers the decision itself, how long ISO 27001 takes covers the timeline, and the cost breakdowns cover what each one runs to.
Engagement note. The work described here is complete and delivered. The engagement continues into audit, and the client is unnamed at this stage of the programme.