Strategy, Compliance & Planning
Updated
Multi-site IT governance fails at two extremes. Total centralization makes every local need wait for headquarters, while uncontrolled autonomy creates incompatible systems, uneven security, and surprises during incidents. A federated model keeps a small set of enterprise decisions central, delegates defined operating choices to sites, and gives legitimate exceptions an owner, expiration date, and evidence trail.
This is not a guide to selecting an MSP. A provider can operate controls and advise leaders, but governance determines who has authority to set standards, approve risk, fund changes, and accept site exceptions. NIST Cybersecurity Framework 2.0 added a Govern function covering organizational context, risk strategy, roles and authorities, policy, oversight, and supply-chain risk. NIST emphasizes that the framework is outcome-based and does not prescribe a single implementation, making its CSF 2.0 resources useful for structuring decisions across different sites.
Define three decision levels
- Enterprise standard: Decisions where inconsistency creates shared risk or destroys economies of scale. Examples can include identity architecture, minimum security outcomes, approved network patterns, incident severity, data classification, strategic vendors, and evidence requirements.
- Site operating choice: Decisions a location may make inside the standard, such as training schedules, local equipment placement, maintenance windows, on-site escalation contacts, and workflow-specific continuity steps.
- Time-bound exception: A documented departure from the standard because of a vendor limitation, facility constraint, acquisition transition, contractual commitment, or mission need. It is a decision to manage, not an undocumented workaround.
Do not centralize a decision just because it involves technology. Centralize it when the choice affects shared identity, data, connectivity, contracts, incident containment, recovery, or enterprise reporting. Delegate when local knowledge materially improves execution and the choice stays within an approved boundary.
Decision-rights matrix
Use roles rather than individual names in the policy, then map current people in the operating register. “Consult” means input is required before the decision; it does not create a second approver. “Execute” identifies the team that implements an approved choice.
| Decision | Approve | Recommend | Consult | Execute | Evidence |
|---|---|---|---|---|---|
| Enterprise identity and access standard | Executive risk owner | IT or security leader | HR, operations, privacy, site leaders | Central IT or provider | Standard, role matrix, exceptions, review results |
| Site technology within approved catalog | Site budget owner | Site operations | Central IT and procurement | Assigned support team | Business need, compatibility check, asset record |
| New enterprise platform | Named steering body or executive | Business and technology sponsor | Sites, finance, security, privacy, procurement | Program owner | Decision record, requirements, risk and exit plan |
| Temporary departure from security standard | Designated risk authority | Control owner | Site owner, security, legal or compliance as needed | System owner | Exception record, compensating measures, expiry |
| Incident containment affecting multiple sites | Incident authority defined in plan | Incident lead | Operations, communications, legal, affected sites | Response team | Chronology, approvals, impact and recovery record |
| Site continuity procedure | Site operations owner | Local workflow lead | Central continuity and IT | Site team | Procedure, exercise result, unresolved dependencies |
The NIST CSF frequently asked questions explains that Govern elevates risk tolerances, roles, responsibilities, and policies so cybersecurity aligns with enterprise risk management and legal obligations. Use that principle beyond cybersecurity: a decision is not governed until the authority, required input, expected evidence, and escalation path are explicit.
Site-exception matrix
Maintain one enterprise register. An email approval or permanent “temporary” workaround is not enough. Rank exceptions by operational impact and exposure rather than allowing the loudest site to set priority.
| Required field | Question it must answer | Example |
|---|---|---|
| Standard and scope | What requirement is not met, at which site, system, users, and data? | Legacy diagnostic device cannot use the enterprise authentication method |
| Business rationale | Why is compliance not currently practical, and what service depends on the exception? | Replacement requires vendor validation during the next capital cycle |
| Risk and dependency | What could happen, what other sites or services are affected, and what assumptions apply? | Local compromise could reach a shared network unless isolated |
| Compensating measures | What reduces exposure while the exception exists, and who monitors it? | Dedicated segment, restricted communication, inventory alert, monthly review |
| Owner and authority | Who is responsible for resolution and who accepted the exception? | Site operations owner; designated enterprise risk approver |
| Dates and triggers | When does approval expire and which event forces earlier review? | 90 days; vendor upgrade, incident, ownership change, or failed control |
| Exit plan and evidence | What closes the exception and how will closure be verified? | Replacement commissioned, segmentation removed, asset and test records updated |
An exception may be approved, denied, remediated, avoided by changing the workflow, or escalated for an enterprise decision. Approval does not make the underlying condition disappear. Report active exceptions by age, exposure, and resolution blocker, and require the approver to revisit them at expiration.
Use a small, durable governance cadence
Weekly operations: Site and support leads review service disruptions, urgent access issues, implementation blockers, and exceptions approaching a trigger. This meeting coordinates work; it should not silently change enterprise policy.
Monthly control review: Control owners examine missing assets, overdue access decisions, untested recovery dependencies, failed standards, supplier issues, and exception aging. NIST provides CSF Organizational Profile resources for comparing current and target outcomes; a multi-site organization can use a common target while recording different current states.
Quarterly leadership review: Executives decide priorities, funding, risk treatment, standards, and material exceptions. Reports should show business-service impact, trend, decision requested, alternatives, owner, and due date. Totals without thresholds or decisions are operational telemetry, not governance.
Event-driven review: Acquisitions, new sites, major vendors, significant incidents, regulatory changes, insurance requirements, and material architecture changes should reopen relevant standards and exceptions. Waiting for a quarterly calendar can preserve a decision whose assumptions no longer hold.
Make evidence comparable across sites
Standardize the question before standardizing every tool. Each site should report the same minimum evidence for asset coverage, identity changes, privileged access, backup and restore tests, critical incidents, supplier dependencies, training or exercises, and active exceptions. A central team can then compare outcomes even when acquired sites temporarily use different platforms.
CISA's voluntary Cross-Sector Cybersecurity Performance Goals identify a prioritized set of baseline cybersecurity outcomes. The CISA Secure by Design program also emphasizes that technology manufacturers should take greater ownership of customer security outcomes. Use vendor evidence and secure defaults in procurement, but do not let a vendor assertion replace enterprise acceptance testing or local workflow validation.
Handle suppliers as part of governance
Multi-site organizations often inherit local internet providers, alarm systems, line-of-business applications, building controls, and support relationships. The enterprise vendor register should identify service owner, covered sites, data and access, critical dependencies, contract dates, incident contacts, assurance evidence, recovery commitments, and exit method. NIST's Cybersecurity Supply Chain Risk Management program provides official resources for integrating supplier risk into broader governance.
Do not confuse a centralized contract with a governed service. A national vendor can still have different configurations, unsupported equipment, and local workarounds at each location. Conversely, a local vendor can operate inside enterprise standards when its scope, access, evidence, and escalation are controlled.
A 60-day implementation sequence
- List the 10 to 15 recurring technology and risk decisions that currently move between headquarters, sites, and providers.
- Classify each as enterprise standard, site choice, or exception; assign one approval role and one execution owner.
- Publish the decision-rights matrix and test it against a real access request, vendor purchase, outage, and security exception.
- Build the exception register from known workarounds and unsupported assets. Assign an expiration and resolution plan rather than granting blanket grandfathering.
- Define the minimum site evidence packet and a monthly review with thresholds that trigger a decision.
- Run one cross-site incident or continuity exercise. Record where authority was unclear and update the matrix before buying more tooling.
Use the leadership decision framework to structure approvals, the board reporting cadence to elevate material decisions, and the service continuity framework when a shared vendor or platform is changing.
Official sources
- NIST Cybersecurity Framework 2.0 Resource Center
- NIST Cybersecurity Framework Frequently Asked Questions
- NIST CSF 2.0 Organizational Profiles
- CISA Cross-Sector Cybersecurity Performance Goals
- CISA Secure by Design
- NIST Cybersecurity Supply Chain Risk Management
Suggested next step
Take one unresolved site request and force it through the decision-rights and exception matrices. Every blank cell is a governance defect worth fixing. Book a discovery call if Cloud Core MSP can help facilitate that operating-model review.