Does a data center need SOC 2, and what does the examination test?
A colocation provider that customers ask about SOC 2 answers with a SOC 2 report issued by an independent CPA firm, either a Type 1 covering the design of controls at a point in time or a Type 2 adding an opinion on how those controls operated over a period. The report covers the Security category, the common criteria CC1 to CC9, plus whichever of the availability, confidentiality, processing integrity and privacy categories the provider chooses to include. For a facility, the most weight usually falls on CC6.4, which requires physical access to data center facilities, backup media storage and other sensitive locations to be limited to authorized personnel, and on the availability criteria A1.2 and A1.3. A1.2 covers environmental protections, backup processes and recovery infrastructure, and A1.3 requires the recovery plan procedures to be tested. Customers often treat the availability criteria as the part that matters most for a facility, so the provider should expect them to be read closely.
Whether a given facility needs this report, and what the examination must test, depends on scope. The system description and the controls differ by site, by service (for example, colocation cabinets, managed power, or cloud on-ramps) and by what the provider runs on behalf of tenants. A provider with several campuses has to decide whether each site sits inside the same report or needs its own. Tenant-facing controls, such as how customer access requests are approved or how a tenant's equipment is decommissioned, belong in the system description only if they are actually part of the service. Illustrative example: a provider that rents cages in one building but operates a remote hands service from another should confirm early whether both are in scope before the examination starts, because the population of controls to test changes with that answer.
The organization owns its controls and the description of its system. DeployOpen plans, implements and documents the systems and evidence that support them, such as access logging, visitor and badge records, environmental monitoring alerts and recovery test records, when those are in its written scope. DeployOpen does not issue audit reports, attestations or certifications; only the independent CPA firm does. Before engaging anyone, ask the CPA firm which facilities, services and subservice organizations it expects in scope, and confirm with the operator of the facility how far its own controls extend. For background on the criteria themselves, the AICPA 2017 Trust Services Criteria with revised points of focus is the primary source to read alongside this section.
What A1.2 and A1.3 ask for in environmental protection and recovery testing
A1.2 asks the organization to authorize, design or acquire, implement, operate, approve, maintain and monitor the environmental protections, software, backup processes and recovery infrastructure that support availability. For a data center, the environmental side covers the things that can take a facility down without any cyberattack: power loss, cooling failure, fire, water intrusion and temperature excursions. The points of focus ask whether the organization identified these threats, installed detection and protection mechanisms, set alerts and defined responses, and kept those controls under maintenance. An assessor will usually test this by selecting a sample of environmental alerts and following each one to its response ticket, then checking that maintenance of generators, UPS units, cooling and fire suppression happened on schedule.
- Threat identification: A documented list of environmental threats for each site, such as utility outage, heat load, flood exposure and fire risk, tied to the risk assessment.
- Detection and alerts: Sensor configuration for temperature, humidity, power and leak detection, with alert thresholds and records of alerts raised.
- Response records: Tickets or shift logs showing who received each alert, what action was taken and when the event closed.
- Maintenance logs: Service records for generators, transfer switches, UPS batteries, cooling units and fire suppression, produced by the vendor or internal staff.
- Maintenance logs: Service records for generators, transfer switches, UPS batteries, cooling units and fire suppression, produced by the vendor or internal staff.
Confirm with your own facilities team which of these records already exist, how long they are retained and whether any monitoring tool is configured to export them for the auditor.
The backup points of focus under A1.2 ask the organization to decide which data requires backup, perform the backups, store copies offsite and maintain alternate processing infrastructure. A colocation provider usually does not own the tenant data, so the provider's scope is typically its own operational data, such as configuration backups for its management systems, access system databases, monitoring history and the records that support its own recovery. Tenants will expect the provider to describe what it backs up for itself and what it does not back up on their behalf. Where a provider does run backup services for tenants, those services fall inside the examination and need their own evidence.
- Backup scope decisions: A written list of which provider systems require backup, with the reasoning for each.
- Backup job records: Logs showing jobs ran, completed and failed, with failures followed up.
- Offsite copies: Evidence that copies are stored at a separate location, with access restricted in line with CC6 criteria.
- Alternate processing: A description of where management systems run if the primary site fails, and whether that location is tested.
- Restore evidence: Records of restores, which connect backups to the recovery tests discussed in the next tab.
Ask your auditor early whether the scope of backups for your own systems or for tenant services will be included in the description of the system.
A1.3 requires the organization to test the recovery plan procedures that support system recovery. A written plan that has never been exercised does not satisfy this criterion, and an assessor will look for evidence that tests were run, what they covered and what happened afterward. For a data center, a useful test might simulate loss of utility power, a failed cooling unit or the loss of a building zone, then confirm that generators start, tenant-facing services stay within their stated commitments, and staff follow the runbook. The test does not have to be a full facility shutdown, but it should be realistic enough to show that the procedures work in practice.
- Test plan: A schedule of recovery tests with the scenarios covered, the systems in scope and the owner of each test.
- Test reports: Records of what was tested, when, by whom, what passed, what failed and the observed recovery time.
- Corrective actions: Tracked tickets for every gap found, with an owner and a closure date.
- Plan updates: Revisions to the recovery plan that follow lessons from each test.
- Participation records: Attendance or sign-off by the people named in the plan.
Confirm with your auditor how many tests and which scenarios they expect to see during the observation period, because this varies with the scope of the report.
The availability category is optional in a SOC 2. The common criteria apply to every SOC 2, but A1 criteria are added only when the organization decides availability belongs in scope, usually because customers rely on uptime commitments. A provider that includes availability will need the A1.2 and A1.3 evidence described in the other tabs for the full observation period of a Type 2 report. A provider that excludes availability will not receive an opinion on these criteria, although customers may still ask about power and cooling through other documents or questionnaires.
- Inclusion decision: A documented reason for including or excluding availability, agreed with the auditor before fieldwork.
- Service commitments: Any uptime or recovery commitments in customer contracts, which must match what the system description says.
- Carve-outs: Clear treatment of power, cooling or network providers that are subservice organizations, with their reports reviewed.
- Description consistency: Matching statements in the system description, the trust page and sales materials about environmental and recovery controls.
- Scope changes: A record of any change to the availability scope during the year, since that affects what the auditor tests.
Before committing to availability in scope, confirm with your CPA firm how the decision will be documented and what it means for customer communication.
What tenants inherit in their own SOC 2 reports and what they keep
A tenant's SOC 2 report can rely on part of the provider's controls, but only the parts the provider's report actually covers. The cards below separate what is inherited, what is shared, what the tenant still owns inside its own cage or rack, and what the tenant must operate itself.
Physical and environmental controls
Access to the facility, environmental protection and recovery infrastructure are usually the provider's controls under CC6.4 and A1.2. A tenant can cite the provider's SOC 2 report for these, provided the report covers the specific facility and the period the tenant needs. Check that the provider's report covers the facility you occupy, not only a parent company or a different site. Ask whether environmental monitoring alerts reach the provider's operations team and how they are escalated.
Shared patch and configuration management
Some controls split between the provider and the tenant. Where the provider patches the facility's building management, network core or hypervisors, it owns that layer, while the tenant patches its own servers and devices. The AWS shared responsibility model illustrates this pattern: physical controls are inherited, while patching and configuration are shared, with each party covering its own scope. Ask the provider exactly which layers its report covers, then document your side in your own system description.
Zone security and cage controls
Inside a shared facility, the tenant decides who may enter its cage, rack or suite. Those controls are the tenant's to design, operate and evidence: the access list, badge requests, escorted visits, and removal of access when staff leave. The AWS model lists zone security as a customer-specific control for the same reason. Keep a current access roster, reconcile it against the provider's visitor logs, and retain the approvals. Assessors will test these records directly against your own CC6.4 control.
Complementary user entity controls
The provider's report usually lists complementary user entity controls, which are controls the tenant must operate for the provider's controls to work as described. Examples include restricting who requests physical access on your behalf, reviewing your own rack inventory and reporting incidents to the provider. Missing one of these creates a gap that the provider's auditor cannot close for you. Map each listed control to an owner and evidence in your own control matrix before your audit window opens.
Asset disposal and media handling
Disposal of drives and hardware under CC6.5 can sit with the provider or with the tenant, depending on the contract. Tenants that keep their own drives in the facility must keep protections on those assets until the data is unreadable and no longer needed, and must document destruction or return. Confirm in writing who removes, wipes and certifies disposal of your media, and whether the provider's report covers that process for your assets.
Bridge letters and report gaps
A provider's report has a fixed period, and your audit window may start or end later. A bridge letter is a management statement from the provider covering the gap between the report's end date and your period. Request the provider's current report and any bridge letter early, read the scope and subservice carve-outs, and note any exceptions. Confirm the letter's wording and date range with your own CPA firm before relying on it.
How a colocation SOC 2 moves from scoping to report
The sequence turns a data center's facilities, services and subservice providers into a described system, tested controls and an independent CPA opinion that tenants can rely on. Each phase produces a defined artifact that the next phase depends on.
Scope the facilities, services and subservice providers
The organization decides which sites, buildings, managed services (such as power, cooling, remote hands or cross-connects), and hosting platforms fall inside the examination, and which Trust Services categories apply beyond the common criteria. Security is always in scope; availability is the category most colocation providers add, and the decision should be recorded with the reason. Subservice providers such as power suppliers, security guard contractors, cloud hosts, or equipment disposal firms are identified next, and the organization confirms whether each will be carved out or covered by its own SOC report. Done means a written scope statement that the CPA firm and management have both reviewed, which the engagement letter references. Confirm with your CPA firm how timelines for this phase will be stated in the written engagement letter.
Write the system description
Management prepares a description of the system covering infrastructure, facility layout, physical security zones, environmental equipment, personnel roles, data flows for tenant services, and the boundaries with subservice providers. The description follows the AICPA 2018 description criteria, which ask for the system as it operates, not as it is designed to operate. Engineering, facilities operations and the security team each review their sections, and the CPA firm checks completeness against the criteria. Done means an approved description that management can point to in every later phase, because tenants will read it to understand what their own reports inherit.
Map controls to CC6.4, CC6.5, A1.2 and A1.3
The control matrix links each in-scope criterion to a named control, owner, frequency and evidence source. For colocation, CC6.4 covers restricting physical access to data halls, cages and backup media storage, with controls for granting, changing, removing, recovering and reviewing access. CC6.5 covers keeping protections on physical assets such as drives and servers until their data cannot be read or recovered. A1.2 covers environmental protections, backup and recovery infrastructure, and monitoring of power, cooling and fire systems. A1.3 covers testing of recovery plan procedures. Where the facility relies on a provider such as a cloud platform, the matrix records which controls are inherited, shared or customer-specific, using that provider's published responsibility model. Done means every in-scope criterion has an owner and an evidence source that a sampler could pull.
Run the readiness review
Before the examination period starts, the organization or its implementation partner tests the controls against the matrix, looking for gaps such as badge reviews that are not documented, decommissioning steps that skip media sanitization records, or recovery tests that were run but not written up. Remediation happens here, while changes are still cheap to make. A readiness review does not replace the auditor's work, and the partner prepares evidence but does not issue any opinion. Done means a list of open gaps, each with an owner and a closure check, and a decision by management about whether to proceed to the observation window.
Operate controls through the observation period
For a Type 2 report, controls must run during a defined observation period, and the auditor tests operating effectiveness across that window. Facilities teams keep access reviews, visitor logs, environmental alarm records, backup logs and disposal certificates as part of normal operations. Changes to controls during the period are logged and explained, because the auditor will ask about them. A Type 1 report skips this window and covers design as of a date. Done means a complete, dated evidence set for each control across the period, and a management representation letter prepared for signature at the end, as the AICPA illustrative letter describes.
Complete fieldwork and sampling
The CPA firm requests evidence, selects samples from the population of events in the period (for example, a set of access grants, a set of drive disposals, or a set of recovery tests), and tests each sample against the control description. Exceptions are logged, discussed with management, and either explained or evaluated for their effect on the opinion. Tenants' complementary user entity controls, such as their own access reviews for their cages and their own backup decisions, are documented so that the report states clearly what the provider does and what the tenant must do. Done means signed workpapers, a resolved exception list, and agreement on the factual accuracy of the system description.
Issue the report through the CPA firm
Only the independent CPA firm issues the SOC 2 report, which contains the auditor's opinion, management's assertion and description, the criteria tested, and the test results and exceptions. Management decides how it will share the report, and tenants review it under their own NDA terms. A SOC 3 may be produced for general distribution, but it carries less detail. Done means a signed report with a period end date that customers can read against the system description and the complementary user entity controls. Confirm with the firm how the report and any bridge letter will be delivered, and how the next period will be scheduled.
When a tenant's auditor also asks for a SOC 1
A SOC 1 is a different examination from a SOC 2, and a colocation or hosting provider is usually asked for one only when a tenant's financial statements depend on the systems that run in the facility. A SOC 1 examines controls at a service organization that are likely to be relevant to user entities' internal control over financial reporting. Its intended users are the user entities themselves and the CPAs who audit their financial statements. A SOC 2, by contrast, is written for customers and prospects who need assurance over the Trust Services Criteria, including the physical access, environmental and recovery criteria that a data center already runs. The two reports overlap in the facility controls but answer different questions for different readers.
The practical trigger is usually a tenant that runs ledgers, payment processing, payroll or reporting systems in your space and whose external auditor plans to rely on your controls as part of their own testing. In that case the tenant's auditor, not the tenant's security team, is often the party who sets the requirement. Before you scope anything, ask the tenant which report their auditor needs, whether that is a SOC 1, a SOC 2, or both, and which control objectives their auditor expects to see. Ask also for the period the auditor needs covered and the date by which a report must be delivered. Those answers decide whether you scope a SOC 1 alongside your SOC 2, and they prevent you from building a report that the tenant's auditor cannot use.
Confirm with the tenant's auditor, and with your own CPA firm, whether the control objectives they need are already covered by your SOC 2 criteria or require separate treatment. Your independent CPA firm, not DeployOpen, decides the report type and issues the opinion. DeployOpen can prepare the environment, documentation and evidence for the controls in scope, including the physical access and environmental records a tenant's auditor will ask to see, but the scope and report selection belong to the service organization and its auditor. Settle the scope in writing before fieldwork starts so that the SOC 1 and SOC 2 do not drift apart on system descriptions or control wording.
What makes a data center SOC 2 larger or smaller
A data center SOC 2 grows or shrinks with a few decisions made before the examination starts. Each driver below changes how many controls are tested, how many vendors appear in the system description, and how much evidence the auditor must sample.
Number of facilities in scope
Each facility that holds customer equipment or supports the services in the system description adds physical access, environmental and recovery testing. Providers often start with one flagship site and add others later, which can force a new Type 2 observation period for the added locations. Confirm with your auditor whether each site is included in the same report or handled as a separate system. Keep a current list of sites, their roles and their access paths so the scope does not drift between audit periods.
Operated or leased space
A provider that owns and runs its building controls the full physical and environmental stack, while a provider that leases space from a landlord or wholesale host must decide which controls it inherits and which it tests itself. Lease terms, landlord access rights and the host's own SOC reports determine that split. Where the host's report covers the building, the provider documents the boundary and its own complementary controls. Ask the auditor how the boundary will be described before the lease is signed.
Availability criteria included
Adding the availability category brings in A1.2 on environmental protections, backups and recovery infrastructure, and A1.3 on testing recovery plan procedures. Without availability, the report focuses on security controls such as physical access. With it, the auditor examines power, cooling, fire detection and suppression, and whether recovery tests were actually run during the period. Many colocation customers ask for availability, so decide early and document which environmental threats each site has identified.
Subservice organizations
Power utilities, generator and UPS maintenance firms, fire suppression contractors, cleaning services and security guard companies each perform work that affects controls. Each one is either carved out of the report or included as a subservice organization with its own monitoring. The more vendors that touch the facility, the more vendor reviews, contracts and reports the auditor must read. Build a register that names each vendor, the control it supports and whether its own SOC report or certificate is on file.
Maturity of access records
Physical access is tested through the creation, modification, removal and periodic review of badge and visitor rights. Providers with paper logs, shared badges or reviews that happen only before an audit tend to generate more exceptions. Consistent badge provisioning tied to HR or contract start and end dates, documented quarterly reviews and escorted visitor logs make sampling simpler. Ask for a sample of the last few quarters of access reviews to see whether they are complete and signed.
Maturity of evidence records
Auditors test operating effectiveness by sampling records across the full observation period, so the size of the report depends on how easily those records can be retrieved. Alarm histories, environmental sensor logs, generator test results, disposal certificates for drives and recovery test reports should be stored in a consistent format with dates and owners. Organizations that gather evidence at audit time usually need more time and produce more exceptions. Confirm which system holds each record and how long it is retained.
Type 1 or Type 2, and SOC 2 or SOC 1: which report a colocation provider picks
This table compares the SOC 2 Type 1 and Type 2 reports and the SOC 2 and SOC 1 examinations for a colocation provider. Read each row against your customer contracts and the controls your tenants rely on, then confirm the report type with your CPA firm before fieldwork starts.
| Question | SOC 2 Type 1 | SOC 2 Type 2 |
|---|---|---|
| What it covers | The system description and whether controls are suitably designed as of one date | The same design review plus an opinion on whether controls operated effectively over a period |
| Best fit for a colocation provider | A first report while new physical access or environmental controls are still being bedded in | Tenants who ask how facility controls performed over time, such as badge reviews and environmental alarm response |
| Typical tenant question it answers | Were the controls designed to meet CC6.4 and A1.2 when we looked? | Did physical access reviews and recovery tests run as described across the period? |
| Effect of a gap | Design weaknesses appear as exceptions in the description or opinion | Operating exceptions, such as a missed access review, appear in the report and drive customer follow-up |
| Question | SOC 2 (for tenants and general IT buyers) | SOC 1 (for tenants' financial reporting) |
| Who uses the report | Tenant security, compliance and procurement teams assessing the facility | User entities and the CPAs auditing their financial statements |
| When it is requested | When tenants hosting customer data or regulated workloads ask about security, availability or confidentiality | When a tenant's financial statement auditor considers the facility relevant to internal control over financial reporting |
| Reading the SOC 3 | A SOC 3 is a general use report covering the same categories in less detail and can be freely distributed | Use of a SOC 2 report is generally restricted, so share it under NDA with tenants that have a need to know |
Who owns controls, who prepares evidence and who issues the report
The provider's facilities, security and operations teams own the controls. Management decides what the physical access policy says, who is authorized into the data hall, how environmental alarms are answered and which recovery tests are run. These decisions must be made and carried out by the provider's own people, because the SOC 2 report describes the provider's system, not a partner's.
- Physical access administration: staff grant, change and remove badge and biometric access, and recover cards and keys when someone leaves.
- Environmental operations: the team monitors power, cooling, fire suppression and water detection, and responds to alerts.
- Asset disposal: the provider decides how drives and media are wiped or destroyed and keeps the chain-of-custody records.
- Recovery testing: the provider schedules and performs recovery plan tests and records the results.
- Management review: leadership reviews access logs, incidents and exceptions on a set cadence.
Ask the provider which named role owns each control in its control matrix, and whether those owners can produce evidence without a partner's help.
DeployOpen works as an implementation partner for the systems and documentation that sit behind the controls. Where a provider runs self-hosted open-source platforms for ticketing, access logging, monitoring, backup or configuration management, DeployOpen can plan, build, harden, document and support those platforms inside the provider's own infrastructure. DeployOpen prepares systems, controls and evidence for the assessment. It does not perform the examination, does not write the opinion and does not certify the provider.
- Systems build: configuring access logging, alerting, backup jobs and configuration baselines on platforms the provider owns.
- Evidence preparation: setting up exports, retention and naming so that records can be pulled for the auditor's samples.
- Documentation: drafting runbooks and procedures that the provider's management reviews, approves and adopts.
- Testing support: running security testing on the systems in scope and recording findings and remediation.
- Ongoing support: upgrades and monitoring, under a retainer if the provider wants continuity between audits.
Confirm in the written scope which controls DeployOpen touches, who approves each document, and that the provider keeps administrative ownership of every system after handover.
An independent CPA firm performs the SOC 2 examination and issues the report. The firm tests the design of the controls and, for a Type 2 report, their operating effectiveness across an observation period. Independence means the auditor cannot be the party that built the controls or prepared the evidence it tests, so the firm must keep its own judgment separate from any consultant's work. The examination follows the attestation standards, and management provides written representations that the auditor relies on.
- Design and operating tests: the firm selects samples, inspects evidence and reports exceptions.
- Management representations: the provider signs representations, including its system description and its assertion about the controls.
- Report issuance: only the CPA firm issues the SOC 2 report and its opinion.
- Engagement terms: scope, period and fees are set in an engagement letter between the firm and the provider.
- Subservice organizations: the firm reviews how carve-outs, such as a colocation provider's own power or fire vendors, are treated.
Ask the firm how it handles independence when a consultant also prepares evidence, and whether it has reviewed the planned scope before fieldwork begins.
Some work is commonly bought in, and some should stay with the provider's staff. The split depends on the provider's size and on how much of the facility is owned or leased. Outsourcing a task does not transfer the control, and the provider remains answerable for the result in its report.
- Commonly outsourced: SOC 2 readiness support, evidence collection tooling, penetration testing, security monitoring platforms and third-party recovery exercises.
- Commonly kept in house: physical access approvals, badge administration, asset disposal authorization, incident decisions and management review.
- Shared or vendor-run: power, cooling and fire systems maintained by specialist vendors, whose own reports may need to be carved out.
- Recurring cost: access logging, monitoring and retainers for ongoing support run every month, while readiness and the first examination are largely one-time.
- Quote terms: ask each partner to list deliverables, the named owner on the provider side and what is excluded.
Before signing any engagement, confirm in writing which controls each party owns and which vendors are carved out of the report.
Questions colocation providers ask about SOC 2
Is a SOC 2 required for a colocation provider?
No law requires a SOC 2 by itself, but most enterprise tenants, especially banks and insurers, ask for one in due diligence or contracts. A SOC 2 is a voluntary examination that a CPA firm performs, and it tests whether your controls meet the 2017 Trust Services Criteria for the systems and services in scope. For a colocation provider, the security category applies to every SOC 2, and the availability category is commonly added because tenants buy uptime and facility resilience. Ask your largest or most regulated tenants which report they need before you decide the scope.
What drives the cost and effort of a colocation SOC 2?
The cost has two parts: the internal effort your team spends, and the fees paid to the CPA firm for the examination. Internal effort is driven by the number of sites, how many controls already exist in writing, the state of your access logs and visitor records, and whether your facility vendors (security guards, cleaning contractors, fire and power maintenance providers) must be covered. Auditor fees are driven by the report type, the number of locations tested, the observation period and the sample sizes the auditor selects. One-time costs include the readiness assessment and gap remediation; recurring costs include the annual examination, control monitoring and evidence collection. When requesting a quote, ask the firm to itemize fees by site, by category and by Type 1 versus Type 2 work, and to state which items you must prepare yourselves.
How long does a SOC 2 Type 2 observation period run?
A Type 2 report covers operating effectiveness over a period of time, and the observation window is set by agreement between you and the auditor. Many first-time providers choose a period long enough to show controls working consistently across the facility's normal operating cycle, and then renew the report on a recurring schedule. The period must be long enough for the auditor to select samples across it, so a short window produces fewer tests and may be less useful to tenants. Confirm the period length, the start date and the bridge requirements with your CPA firm before you begin, because the length affects both timing and the evidence your team must keep throughout.
Can tenants rely on the provider's SOC 2 report?
Tenants can read your report and use it as evidence about the controls you run, but they cannot treat it as proof of their own compliance. Your report describes your physical access, environmental protections, asset disposal and recovery testing. Tenants still own their logical controls inside their racks, their cages' contents, their backups and their data classification. Many tenants include the report in their vendor oversight file and then map the complementary user entity controls to their own program. Expect tenants to ask for a bridge letter if the report period ends before their contract renewal, and expect them to read the exceptions section closely. Your SOC 2 general use summary, if you issue one, can be shared more widely than the full report, which is restricted to specific users.
Does a colocation provider also need a SOC 1 report?
A SOC 1 is needed only when your customers use your services in their internal control over financial reporting and their financial statement auditors ask for a report. A SOC 1 examines controls relevant to user entities' financial reporting, so it is a different scope from SOC 2. Some colocation providers host financial systems for banks, payment processors or trading firms, and those customers often request a SOC 1 alongside a SOC 2. Ask your key tenants and their auditors whether they need the report. If the answer is yes, decide early whether one examination can serve both purposes or whether separate reports are required, because the control descriptions and audit approach differ.
What must our team provide for a SOC 2 examination?
Your team owns the controls and provides the evidence the auditor tests, and an implementation partner can help you prepare it. Expect to supply a written system description, a control matrix, policies and procedures, and a management assertion. For physical controls, you will provide access badge records, visitor logs, camera retention settings, cage and rack access lists, removal and disposal certificates, and records of your environmental monitoring and alerts. For availability, you will provide backup and recovery plans, restoration test results and evidence of capacity reviews. Assign a named owner for each control, set up a repeatable evidence calendar, and keep records from the first day of the observation period. Ask the auditor for a written list of evidence requests before fieldwork begins.
Can we prepare for SOC 2 ourselves or do we need outside help?
You can run a SOC 2 readiness effort with internal staff, but the examination itself must be performed by an independent CPA firm, which issues the report. Outside help is most useful for gap assessments, control design, evidence automation and recovery testing, where specialist experience shortens the timeline. An implementation partner such as DeployOpen can prepare systems, controls and evidence in your own environment, but it does not issue audit reports or attestations. Consider whether your team has the capacity to maintain evidence for the full observation period, since a gap in records is one of the most common reasons for exceptions in a Type 2 report.
How DeployOpen prepares a data center for its SOC 2 examination
DeployOpen starts with a written scope statement that names the facilities, the cages or suites in each facility, the power, cooling and network infrastructure, the ticketing and access systems, and the customer-facing service the examination covers. The statement also separates what the operator owns from what it inherits from a subservice provider, such as a colocation landlord, a cloud host or a fire suppression contractor. That boundary decides which controls are tested in the operator's own report and which are carved out and supported by the other provider's report. Before any build work starts, the scope and the carve-out list are agreed in writing, because every later control, sample and evidence request depends on them. Readers should confirm with their auditor which systems and sites belong in the system description, since the auditor makes that judgment, not DeployOpen.
DeployOpen then implements or documents the controls inside the client's own environment, whether that is their facilities, their network or their cloud accounts. For physical access under CC6.4, this typically means badge and visitor logs tied to an approved access list, periodic access reviews and documented removal of access when staff leave. For the availability criteria under A1.2 and A1.3, it means monitoring of environmental sensors, backup and recovery runbooks, and recorded recovery tests. Open-source tools can capture some of this evidence, such as exported access logs, alert histories and infrastructure-as-code change records, but the operator must confirm that each tool produces records the auditor can rely on, and that the staff who run them are trained and accountable. DeployOpen also documents how evidence is collected, stored and retained so that the operator, not an outside contractor, can keep producing it after the engagement ends.
Before the examination, DeployOpen runs readiness checks against the agreed scope, looking for gaps between the written procedures and what staff actually do. The deliverables include a control matrix that maps each in-scope control to its criteria, owner, frequency and evidence source, and an evidence index that tells the auditor where each record lives and who can produce it. DeployOpen does not issue reports, attestations or certificates. Only an independent CPA firm can perform the examination and issue a SOC 2 report, and hiring DeployOpen does not guarantee that the auditor will find the controls effective or that the report will contain no exceptions. Operators should ask any partner to state the same boundary in writing, and should confirm the scope, deliverables and timeline in the signed statement of work before work begins.
