Governance

Strategic direction

Tie security objectives to business goals and set compliance scope before the design is fixed. Sources: NIST CSF 2.0 (CSWP 29, 26 Feb 2024) Govern function; ISO/IEC 27001:2022 public abstract. Sources checked 6 Oct 2026.

Objectives from business goals

CSF 2.0 added a Govern function that sits above Identify, Protect, Detect, Respond and Recover. It asks for an understood mission and stakeholder expectations (GV.OC), a risk management strategy with risk appetite and tolerance statements (GV.RM-02), and cyber risk handled inside enterprise risk management (GV.RM-03) (NIST CSWP 29). For a data center the useful outputs are a short list of objectives that the infrastructure can be designed and measured against, for example:

• Which services are tier-1, with the RPO and RTO the business accepts (feeds Backup: RPO and RTO)
• Which regulated data the site will hold, and whether it may sit in colo or must stay onsite
• How much downtime from a facility fault is tolerable (feeds the resilience decision on Facility)
• Which customers or contracts require attestations, and which ones

Set compliance scope early

CSF GV.OC-03 asks that legal, regulatory and contractual cybersecurity requirements are understood and managed. In a build, that means a scope statement at step 1 that names each framework, the systems and data it covers, and who confirmed it (legal, compliance, the contracting party). Scope drives design in four ways:

The reference scenario (A11 in the build journey assumptions) assumes a general enterprise posture such as ISO/IEC 27001 with no special regulated enclave. If a regulated enclave is added later, revisit the segmentation model and retention first; both are expensive to change once the fabric and storage are built.

Strategy design / build / manage

Design

• Write the scope statement at step 1: frameworks, systems and data in scope, who confirmed each, and the regulated-data boundary (Scope early)
• Agree the objectives the design is measured against: tier-1 services with RPO/RTO, where regulated data may sit, tolerable facility downtime, required attestations
• Feed RPO/RTO to Backup and the downtime tolerance to Facility; the boundary and retention go out with the requirements register (Requirements register)

Build

• Before go-live, confirm the built boundary matches the scope statement and retention matches the requirements register, as part of the pre-go-live control check. Fix the difference, update the scope, or record it as a risk with an owner. For PCI DSS this is the first 12.5.2 scope confirmation.

Manage

• Review the strategy and objectives at least yearly and after major change
• If a regulated enclave is added later, revisit the segmentation model and retention first

Policies and standards

The document hierarchy and the infrastructure decisions it must cover. Sources: NIST CSF 2.0 GV.PO-01 and GV.PO-02; ISO/IEC 27001:2022 Annex A 5.1; NIST SP 800-88 Rev. 2. Sources checked 6 Oct 2026.

Hierarchy

CSF 2.0 GV.PO-01 and GV.PO-02 ask for policy that is established, communicated and enforced, and reviewed as requirements, threats and technology change. ISO/IEC 27001:2022 Annex A 5.1 covers policies for information security.

Decisions the documents must cover

Each row is a decision the infrastructure teams cannot make alone. If no standard exists, the build team will choose a value and the auditor will ask who approved it.

• Physical access: zones, who approves access, review interval, visitor and escort rules, retention of access records and video (Security: Physical)
• Segmentation: trust zones and what may cross between them (Security: Policy model)
• Cryptography and keys: where data must be encrypted at rest and in transit, approved algorithms and modules, key custody and rotation (Storage: Encryption · Security: Key management)
• Privileged access: admin identities, MFA, session recording, break-glass (Security: Identity)
• Logging: sources, time sync, retention, who reviews, protection of logs (Security: Log sources and volume · Security: Log retention and protection · Security: Time sync · Ops: Monitoring)
• Backup and recovery: copies, immutability, RPO/RTO, restore-test cadence (Backup)
• Change: what needs approval, emergency changes, post-change verification (Ops: Change management)
• Media and equipment disposal: sanitize or destroy, method by media type, certificates, chain of custody
• Suppliers and colo: required attestations, right to audit, incident notice, responsibility matrix

NIST SP 800-88 Rev. 2 (September 2025) is the current NIST guideline for media sanitization programs and is the usual reference for the disposal standard (NIST SP 800-88r2).

Policies design / build / manage

Design

• Get policy approved by executive management or the board; set the standards below it before the build team has to pick values
• Cover each decision in Decisions the documents must cover, including a disposal standard based on NIST SP 800-88 Rev. 2

Build

• Write the procedures and runbooks the owning teams need before cutover: access, crypto and keys, logging, change, backup, media disposal
• Route deviations found during the build through the exception process, with compensating controls and an expiry (Risk acceptance)

Manage

• Review policy at least yearly and when requirements, threats or technology change; update standards when they do
• Re-review exceptions on expiry

Roles and accountability

Who owns the outcome, who does the work, and how that splits with a colo provider. Sources: NIST CSF 2.0 GV.RR; NIST SP 800-53 Rev. 5 (release 5.2.0) PM-2, PM-9 and CA-6; AICPA TSC CC1.2 and CC1.3; HIPAA 45 CFR 164.308(a)(2); PCI DSS v4.0.1 Req. 12.4.1 and 12.8.5; 32 CFR 170.19. Sources checked 6 Oct 2026.

Outcome ownership vs operational tasks

Frameworks separate accountability for the outcome from the work of running controls. Accountability stays with executive management or the board; the tasks can be delegated to security, infrastructure and providers.

• NIST CSF 2.0 GV.RR-01: organizational leadership is responsible and accountable for cybersecurity risk. GV.RR-03 adds adequate resources for the strategy.
• NIST SP 800-53 CA-6: a senior official is the authorizing official who accepts inherited common controls and authorizes a system to operate. PM-2 appoints a senior information security officer to run the program.
• ISO/IEC 27001:2022: top management must show leadership and commitment to the ISMS and assign roles; Annex A 5.2 and 5.4 cover roles and management responsibilities. Verify clause wording against a licensed copy.
• SOC 2 (TSC CC1.2, CC1.3): CC1.2: the board demonstrates independence from management and exercises oversight of internal control. CC1.3: management, with board oversight, sets structures, reporting lines, authorities and responsibilities. These bind only if the organization issues its own SOC 2 report.
• HIPAA 164.308(a)(2): identify one security official responsible for the security policies and procedures.
• PCI DSS v4.0.1 Req. 12.4.1 (service providers only): executive management establishes responsibility for protecting cardholder data and for the PCI DSS compliance program.
• CISA CPG 2.0 goal 1.A: cybersecurity roles and responsibilities are documented, with C-suite and both physical and cyber security staff in scope, and IT/OT teams working together.

What cannot be delegated: setting risk appetite, accepting residual risk, approving policy, and funding the program. A provider or an infrastructure team can run a control, but cannot accept the risk of it failing on the organization’s behalf.

RACI for DC control areas

A starting point to adapt. R = responsible (does the work), A = accountable (one per row, owns the outcome), C = consulted, I = informed. “Exec” is the executive risk owner (often a CIO, COO or CRO, with the board informed); “CISO” is the security function.

In colo, accountability for physical access stays with you even where the provider runs the layer; its share is evidenced through its attestations and the responsibility matrix (Colo shared responsibility). The split in this table is editorial practice, not taken from any one framework. Where a framework names a role (the HIPAA security official, the 800-53 authorizing official), map it to a named person in the A column.

Colo shared responsibility

In colo the provider runs the building, power, cooling and much of physical security, so some controls you are assessed on are its controls. The frameworks handle this in different ways, but the common design need is the same: a written responsibility matrix and evidence for the provider’s share. The layer-by-layer physical split is on Security: Onsite vs colo, and what to ask for when evaluating a provider is on Facility: Colo evidence.

Using a colo provider’s SOC 2 Type 2 report

A provider’s SOC 2 Type 2 report is the usual evidence for its share of physical and environmental controls. It informs supplier due diligence (PCI DSS Req. 12.8.3) and ISO/IEC 27001 Annex A 5.19–5.22 monitoring. It is not a PCI DSS Attestation of Compliance (AOC) and does not show PCI DSS compliance status for Req. 12.8.4. For Req. 9 controls the provider runs, you need the provider’s AOC or its inclusion in your assessment (see the table above). Confirm with your QSA. Verify Read the report, don’t just file it:

An ISO/IEC 27001 certificate is the other common provider evidence. It shows a certified ISMS and its scope, but it has no test results; a SOC 2 Type 2 report shows what was tested and what failed. Facility ratings are separate evidence (Facility: Colo evidence). How carve-out, CUECs and bridge letters are described here follows CPA-firm guidance on the AICPA SOC 2 guide, which is paywalled. Verify

Roles design / build / manage

Design

• Name the executive risk owner and, where a framework requires one, the security official or authorizing official
• Adapt the RACI with one A per row
• Colo: agree the responsibility matrix and get the provider’s attestations before signing (Colo shared responsibility)

Build

• Map each complementary user entity control in the provider’s SOC 2 report to an owner in the RACI
• Colo: file the provider’s attestations and the signed responsibility matrix with your evidence; for CMMC, record any ESP use in the system security plan

Manage

• Collect and read the provider’s SOC 2 Type 2 report each cycle: period, scope, subservice organizations, CUECs, exceptions, bridge letter (Using a colo SOC 2)
• Update the RACI and the CUEC owner mapping when people, providers, control areas, or the CUECs in the provider’s latest report change (editorial practice; no framework sets a cadence)

Risk management

Identify, prioritize, treat and formally accept risk. Sources: NIST CSF 2.0 GV.RM and ID.RA; NIST SP 800-53 Rev. 5 RA-3, PM-9, CA-5; HIPAA 164.308(a)(1); PCI DSS v4.0.1 Req. 12.3.1; ISO/IEC 27001:2022 public abstract. Sources checked 6 Oct 2026.

Process the frameworks share

Most of the in-scope frameworks expect a documented risk assessment that drives control choices; PCI DSS v4.0.1 uses targeted risk analyses for specific requirements, and CSF is voluntary. HIPAA makes risk analysis and risk management required specifications (164.308(a)(1)(ii)(A)–(B)). NIST SP 800-53 has RA-3 for risk assessment and PM-9 for an organization-wide strategy. ISO/IEC 27001 builds the ISMS on risk assessment and treatment, recorded in a Statement of Applicability. PCI DSS v4.0.1 Req. 12.3.1 requires a documented targeted risk analysis wherever you choose your own frequency for a requirement, reviewed at least every 12 months. CSF ID.RA-06 asks that risk responses are chosen, tracked and communicated, and GV.RM-06 asks for one standard method to score risk.

Risk acceptance

• Only the accountable executive accepts residual risk above the agreed tolerance; the security team recommends
• Each acceptance names the risk, the compensating controls, the owner and an expiry date
• Design trade-offs are risk acceptances too: an onsite room left N+1 with single points of failure (Facility: Availability gap), or a legacy OT device that cannot be patched (Security: OT). Record them at design time, not after the audit finds them.
• Re-review on expiry, on a significant change, or when a framework moves a requirement from best practice to mandatory

Risk design / build / manage

Design

• Agree one scoring method and score facility and cyber risks on the same scale
• Record design trade-offs as risk acceptances at design time, with owner, compensating controls and expiry

Build

• Open the risk register with the residual risks from design decisions and the gaps from the pre-go-live control check (Design mapping: pre-go-live check), and get them accepted by the accountable executive
• Open plans of action for gaps that will be closed later (CMMC: POA&M eligibility and 180-day closeout per 32 CFR 170.21) Verify

Manage

• Re-review acceptances on expiry, on significant change, or when a framework moves a requirement from best practice to mandatory
• Review PCI DSS targeted risk analyses (Req. 12.3.1) at least every 12 months
• Record material exceptions in provider reports as supplier risks

Oversight and assurance

Continuous monitoring, periodic audit, metrics, and the evidence the infrastructure must produce. Sources: NIST CSF 2.0 GV.OV and PR.PS-04; NIST SP 800-53 Rev. 5 CA-2, CA-7, PM-31; CISA CPG 2.0 goals 1.B and 3.Q; PCI DSS v4.0.1 Req. 10.7.2, 11.4.5, 12.5.2; HIPAA 164.308(a)(8). Sources checked 6 Oct 2026.

Continuous monitoring and periodic audit

Continuous. NIST SP 800-53 CA-7 asks for a monitoring strategy with defined metrics, monitoring frequencies and ongoing control assessments; PM-31 sets it at organization level. PCI DSS v4.0.1 Req. 10.7.2, mandatory for all entities since 31 March 2025, requires that failures of critical security controls are detected, alerted and addressed promptly, and the list includes physical access controls, segmentation controls and audit logging. Design the monitoring so that a dead camera, a stopped log feed or a bypassed firewall raises an alert, not just an attack. The tooling is on Ops: Monitoring.

Periodic. HIPAA 164.308(a)(8) requires periodic technical and nontechnical evaluation. ISO/IEC 27001 requires internal audit and management review, plus external audits for certification. NIST SP 800-53 CA-2 covers control assessments. PCI DSS validation is annual, through a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance, depending on brand and acquirer rules.

Metrics for the risk owner

CSF GV.OV-01 to GV.OV-03 ask that strategy outcomes and risk management performance are reviewed and used to adjust direction. Report a short set that maps to the risks the executive accepted:

• Restore tests: share passed, and achieved RPO/RTO against target (Backup: Restore testing)
• Patch latency for internet-facing and known-exploited vulnerabilities (Security: Lifecycle)
• Access reviews completed on time; leavers removed within the target; physical access exceptions
• Log source coverage: share of in-scope systems sending logs, and outage minutes of the log pipeline
• Open risk acceptances, and how many have expired
• Audit findings open by age; supplier attestations current

Evidence the infrastructure must produce

Assessors test records, not intentions. Build these outputs into the design so they exist without a scramble before each audit.

Assurance design / build / manage

Design

• Design monitoring so a control failure raises an alert: a dead camera, a stopped log feed, a bypassed firewall (Ops: Monitoring)
• Build the outputs in Evidence the infrastructure must produce into the design
• Choose metrics that map to the risks the executive accepted (Metrics)

Build

• Collect build evidence as you go: diagrams, inventory, configuration baselines, test results, acceptance sign-offs
• Test segmentation (PCI DSS 11.4.5; 11.4.6 for service providers) and restores before go-live and keep the results as audit evidence

Manage

• Run the evidence calendar: PCI DSS scope confirmation every 12 months (12.5.2; every six months for service providers, 12.5.2.1), segmentation tests every 12 months (11.4.5; every six months for service providers, 11.4.6), restore tests, access reviews, supplier reports
• Report metrics to the risk owner on a set cadence
• Run internal audit and management review, and the periodic evaluations the frameworks in scope require

Frameworks compared

The in-scope frameworks: what each is, who it applies to, how conformance is shown, and the current version. ISO standards are paywalled, so ISO facts come from ISO’s public pages and certification-body summaries. SOC 2 facts come from the AICPA Trust Services Criteria (TSP section 100); the AICPA SOC 2 guide is paywalled. Other frameworks (FedRAMP, COBIT, GDPR, NIS2, DORA) are not covered here. Sources checked 6 Oct 2026.

Notes on fast-changing items

• CMMC. On 13 Jul 2026 DoD suspended the Phase 2 transition: solicitations may designate only Level 1 (Self) or Level 2 (Self), existing C3PAO and DIBCAC requirements are being removed, and further guidance was to follow a 60-day CIO review. SP 800-171 Rev. 2 and DFARS 252.204-7012 stay in effect (DoD CIO implementing memo). The review report had not been published at the last check. Verify
• SP 800-171 Rev. 3 vs Rev. 2. NIST published Rev. 3 in May 2024 (fewer, consolidated requirements in 17 families, with organization-defined parameters). DoD class deviation 2024-O0013 keeps DFARS 252.204-7012 on Rev. 2, and 32 CFR 170.14 names Rev. 2 for Level 2. Design to Rev. 2 IDs for CMMC; watch for a move to Rev. 3. Verify
• HIPAA. The proposed rule would remove the required/addressable distinction and require encryption of ePHI at rest and in transit, MFA, an asset inventory and network map reviewed every 12 months, network segmentation, restore of critical systems within 72 hours, vulnerability scans every six months, penetration tests every 12 months, and an annual compliance audit. None of this is in force. Verify
• PCI DSS. The future-dated requirements that bear on infrastructure (for example 3.5.1.2 on disk-level encryption, 10.4.1.1 automated log review, 10.7.2 control-failure detection for all entities, 12.3.1 targeted risk analysis) have been mandatory since 31 Mar 2025. A successor to v4.0.1 is in early consultation. Verify

Frameworks design / build / manage

Design

• Confirm which frameworks apply with counsel, your assessor or the contracting party, and record the version you design to (for example PCI DSS v4.0.1; SP 800-171 Rev. 2 for CMMC)

Build

• Use the IDs of the version in force, not a newer one that is not yet adopted (for example 800-171 Rev. 3 for CMMC)

Manage

• Track the items marked Verify (CMMC, HIPAA, PCI DSS, NIST) and update the requirements register when they land

Design mapping: what frameworks require of the DC

For each design area, the requirement or control IDs that apply, and the page that owns the implementation. This states what is required, not how to build it. IDs: ISO/IEC 27001:2022 Annex A; NIST SP 800-53 Rev. 5 (release 5.2.0); NIST SP 800-171 Rev. 2 (as used by CMMC Level 2); HIPAA 45 CFR 164; PCI DSS v4.0.1; SOC 2 Trust Services Criteria (2017, revised points of focus 2022; A1 and C1 apply only when Availability or Confidentiality is in scope). ISO control titles were checked against secondary lists only. Where a framework leaves a value to the organization (retention, test frequency), the cell says so. Sources checked 6 Oct 2026.

Where several frameworks apply, design to the strictest value in each row and record which requirement set it. For example, PCI DSS fixes minimums for log and access-record retention, while NIST SP 800-53 and SP 800-171 leave the period to the organization.

Mapping design / build / manage

Design

• Build a requirements register from the design mapping, with the strictest value per design area and the requirement that set it
• Hand the boundary to Security, log sources to Security: Log sources and volume, log retention to Security: Log retention and protection, access-record and video retention (PCI DSS 9.2.1.1, 9.3.4) to Security: PACS and Video, RPO/RTO and test cadence to Backup, and provider requirements to Facility

Build

• Run a pre-go-live control check against the requirements register and record the gaps as risks with owners (Risk management)

Manage

• Re-check rows with organization-defined values (retention, test frequency) after significant change
• Update the register when a framework change lands