← All insights

Most organizations of meaningful size answer to more than one regulator. A federal contractor may carry FedRAMP, FISMA, CMMC, and state data privacy laws simultaneously. A multi-state hospital system runs HIPAA, HITRUST, state AI disclosure laws, and FDA software-as-a-medical-device requirements in parallel. A bank lives inside SR 11-7, NYDFS Part 500, FFIEC guidance, SOX, and OCC oversight at once. A SaaS company offering services to those customers has to satisfy SOC 2, ISO 27001, and whatever pass-through control requirements its enterprise buyers add to the contract. The default response is to run a separate program per regulator. The default response is also why most compliance functions are over budget, under-staffed, and exposed at audit time. The answer is a unified control architecture: one set of operational controls, mapped to many regulations, evidenced once and reported many ways.

The short version Parallel compliance programs duplicate controls, fragment evidence, exhaust the second-line teams that have to operate them, and produce audit gaps where the regulators do not overlap cleanly. A unified control architecture inverts the model: build the operational controls once around the most restrictive applicable requirement, document the mapping to every regulator, and let each audit pull the evidence it needs from a single source. The work is front-loaded. The payoff compounds with every new regulator added.

01 Why parallel programs fail

The instinct is reasonable. A new regulation arrives. Leadership assigns a project lead, who staffs a small team, writes policy documents specific to that regulation, and stands up the evidence collection cadence the auditor expects. The team gets to certification. Leadership moves on to the next regulation and repeats the pattern. Three years later, the organization has four programs, four policy stacks, four evidence repositories, four sets of control owners, and four annual audit cycles. The cost is the obvious problem. The harder problem is what happens between the programs.

Consider a hospital system that runs HIPAA, HITRUST, and a SOC 2 program in parallel because its third-party vendors demanded one. The HIPAA program documents access controls in the HIPAA Security Rule format. The HITRUST program documents the same access controls in the HITRUST CSF format. The SOC 2 program documents them in the Trust Services Criteria format. Three policy docs. Three evidence pipelines. When an access control fails (because the underlying authentication system had an outage), all three programs need to be updated. The team updates HIPAA. They forget to update HITRUST. The HITRUST audit two months later opens a finding. The finding triggers a remediation project. The remediation project rebuilds the access control to satisfy the gap. The new control is documented in HITRUST. It is not documented in HIPAA or SOC 2. The cycle repeats next year.

Now run the same scenario across a federal contractor with FedRAMP and CMMC, or a bank with SR 11-7 and NYDFS Part 500. The mechanism is identical. Parallel programs have no mechanism for staying synchronized. Each one is the source of truth for its own framework and a stale copy of everyone else's. Evidence diverges. Findings accumulate. Audit prep becomes a crisis every cycle. The team burns out faster than they can be replaced.

Parallel programs have no mechanism for staying synchronized. Each one is the source of truth for its own framework and a stale copy of everyone else's.

02 The multi-regulator stacks we see

Every sector has a characteristic stack. The composition differs. The pattern of overlap is similar.

Federal contractors and agencies

FISMA at the foundation. FedRAMP if you operate or sell cloud services. CMMC if you handle controlled unclassified information. NIST 800-53 as the underlying control catalog. Sector-specific overlays: agency-specific authorization to operate processes, ICD 503 for intelligence community work, OMB AI-related guidance. New AI procurement clauses like GSAR 552.239-7001 add another reporting and documentation surface. State-level data laws for any data touching state systems.

Healthcare systems

HIPAA Security Rule and Privacy Rule as the floor. HITRUST CSF for organizations that pursue certification. FDA software-as-a-medical-device requirements for any AI or software making clinical decisions. State AI disclosure laws now in force in multiple states. PCI DSS for any organization that handles payments. SOC 2 for any technology services offered to other providers.

Financial services

SOX for public companies and their material processes. SR 11-7 for banks (model risk management). OCC heightened standards for large national banks. NYDFS Part 500 for any organization doing financial-services business in New York. FFIEC examination guidance. PCI DSS for payment processing. State consumer protection and data privacy laws.

Enterprise technology and SaaS

SOC 2 Type II as the table-stakes attestation that enterprise buyers require. ISO 27001 for international and security-conscious buyers. ISO 42001 emerging as the standard for AI management systems. Customer-specific contractual security requirements that pass through whatever framework the customer is on. Sector overlays from any regulated buyer in the customer base (a SaaS selling to hospitals inherits HIPAA business associate agreement obligations; one selling to federal agencies inherits FedRAMP-aligned expectations).

The numbers vary. Three to seven simultaneous frameworks is common for mid-size organizations. Larger organizations and ones operating across multiple sectors can run more than ten. Parallel programs cannot scale to that count without operational collapse.

03 What unified control architecture looks like

The pattern is straightforward to describe and harder to operationalize: one operational control set, mapped to many regulatory frameworks, evidenced once and reported many ways. The pieces are:

A canonical control catalog

One internal catalog of controls that the organization actually operates. NIST 800-53 is the most common starting point because it is the most comprehensive and the federal frameworks already use it. ISO 27002 is a reasonable alternative for organizations primarily in commercial markets. The choice matters less than the commitment to a single source. Every other framework maps to this catalog, not the reverse.

Regulator-by-regulator crosswalks

For each applicable regulatory framework, document which of your canonical controls satisfy which framework requirements. NIST 800-53 to HIPAA crosswalks exist. NIST to SOC 2 crosswalks exist. ISO 27002 to multiple frameworks exists. Where canonical and framework do not align cleanly, document the delta. The crosswalk is a living document. It is the artifact that lets a single control change propagate to every framework simultaneously.

Operational ownership of each control

Every control in the canonical catalog has a named owner. The owner is the operational team that actually runs the control (not the compliance team that documents it). Identity controls live with the identity team. Logging controls live with the platform team. Vendor risk controls live with procurement. The compliance function coordinates. It does not own.

Continuous evidence collection

Evidence is collected continuously from the operational systems that produce it, not assembled annually before an audit. Access reviews come from the IAM system. Change records come from the deployment pipeline. Incident records come from the SOC. Configuration baselines come from the asset inventory. The evidence pipeline is technology, not a quarterly fire drill.

Framework-specific reporting views

Each regulator gets a report formatted for the framework they audit. The data comes from the same continuous evidence pipeline. The report is generated, not assembled. The auditor sees what they need to see in the format they recognize. The work behind it is reusable.

04 Where teams get this wrong

The unified architecture is operationally demanding to set up. Four patterns account for most failed attempts.

Trying to start with the framework rather than the operations

Teams begin by mapping framework requirements to each other and produce an exhaustive control crosswalk before they touch operations. The crosswalk reflects what the regulations say, not what the organization actually does. When the operational reality is layered in later, the crosswalk no longer matches and the team starts over.

Underestimating the canonical-catalog selection

The decision to anchor on NIST 800-53, ISO 27002, or another catalog is treated as a tooling choice. It is a multi-year commitment. Changing the canonical catalog after the crosswalks are built is a project on the scale of the original architecture. Choose deliberately.

Centralizing ownership of operational controls

The compliance team tries to own every control because that is what they own in the parallel-program model. In the unified model they coordinate. Operational ownership lives with the teams that run the systems. Centralizing creates a bottleneck the architecture cannot survive.

Building the evidence pipeline last

The crosswalk and ownership are in place but evidence is still collected by hand before each audit. The unified architecture's payoff comes from continuous evidence. Without it the model is theoretically clean and operationally identical to the parallel-program problem it was supposed to solve.

05 What we would build

The artifact set below is what a working unified architecture looks like in production. Applicable across sectors, with framework-specific details that vary by stack.

  1. The applicable-framework inventory. A documented list of every regulation, framework, contractual obligation, and customer-specific requirement the organization currently answers to. Reviewed annually. Most organizations have not produced this document, and the act of producing it is the most useful diagnostic in week one.
  2. The canonical control catalog. Single source of truth, selected based on the framework inventory. NIST 800-53 for federal-heavy environments, ISO 27002 for commercial-heavy environments, hybrid catalogs for mixed estates. Documented, version-controlled, owned by a named team.
  3. Framework crosswalks for every applicable framework. Every requirement in every applicable framework mapped to canonical controls, with documented deltas where the alignment is imperfect. Maintained as the canonical catalog evolves.
  4. Named operational owners for every canonical control. Identity, logging, vendor risk, change management, incident response, data classification, access reviews. Each owned by the operational team that runs the underlying system.
  5. Continuous evidence collection from operational systems. The IAM system feeds access evidence. The deployment pipeline feeds change evidence. The SOC feeds incident evidence. Annual evidence assembly is replaced by continuous evidence collection feeding a unified store.
  6. Framework-specific reporting views. Generated, not assembled. Each auditor sees the format they expect. The underlying data is the same.
  7. A control change-management process. When a control is added, modified, or retired in the canonical catalog, the change propagates through every crosswalk and every framework view. Owned by the compliance function as a coordination role.
  8. An exception management process. Every framework has gaps. Every implementation has compensating controls. The exception process documents what is missing, why, what compensates, and when it gets remediated. Auditors expect exceptions. They penalize undocumented ones.

06 What to do this quarter

If you are running parallel compliance programs and they are creaking under the load, here is a specific 90 day path toward a unified architecture.

Days 1 through 30: inventory and decision

Days 31 through 60: scaffolding

Days 61 through 90: evidence and reporting

The hardest part of this work is not the technical assembly. It is the cultural shift from compliance-as-a-project to compliance-as-an-operational-discipline. Most organizations have built the first. The firms that scale to many regulators without operational collapse have built the second.

Editor's note This article reflects patterns we have seen across federal contractors, multi-state hospital systems, regional and national banks, and enterprise SaaS companies. The frameworks differ by sector. The architecture pattern does not. Sector-specific deep dives on regulator stacks will publish in the coming weeks.