Your Company Doesn’t Need NIST Controls, ISO Controls, and SOC 2 Controls

It needs company controls. The frameworks should be views of them.

An IAM team conducts a periodic access review. One control execution, one defined population, one set of results, one authoritative body of evidence. That control is then relevant to the SOC 2 examination, the ISO 27001 surveillance assessment, the PCI DSS assessment for the cardholder environment, a customer security questionnaire, and Internal Audit’s testing cycle. Each of those processes may separately request evidence, interpret the results through its own lens, store the artifacts in its own repository, and schedule its own testing procedure.

If the control operated once, why does the organization keep proving that it happened?

This is not principally an auditor problem. It is an architectural problem. An organization should have one control environment built around the risks it actually manages and the controls it actually operates. NIST, ISO 27001, SOC 2, PCI DSS, SOX, internal policy, and contractual requirements should be mapped views of that environment, not separate environments that independently generate controls, evidence requests, and testing. Where requirements genuinely overlap, the most demanding applicable requirement should shape the enterprise control, and the evidence produced by that control should be reused wherever it legitimately satisfies the mapped obligations. The goal is not framework harmonization for its own sake. It is to make the operational control the source of truth and make each framework a view of that truth.

The auditors show up and find five filing systems where there should be one.

How the Architecture Fails

The fragmentation rarely results from a bad decision. It develops naturally, almost invisibly, over time.

An organization adopts SOC 2 as its first formal assurance obligation. A compliance program forms around it: controls are defined, owners are assigned, evidence workflows are established. A year later, a major enterprise customer requires ISO 27001 certification. A specialized ISO program follows, with its own control language, its own documentation structure, its own evidence requests. Internal Audit maintains its own control taxonomy, organized differently still. The security team has been working from NIST CSF since before either audit program existed. And now a subset of the business processes payment cards, so PCI DSS enters the picture, bringing its own prescriptive requirements and testing procedures.

Nobody decided to build five representations of the same operational environment. The result is a control landscape that looks, from the outside, like a mature multi-framework compliance operation, and functions, from the inside, like five separate companies each maintaining their own version of reality.

The conventional flow that produces this outcome:

Framework requirement → framework-specific control → evidence workflow → testing procedure

Repeat for each framework. The controls multiply. The evidence requests multiply. The testing burden multiplies. Control owners, typically operational staff in IT, IAM, DevOps, or finance, receive substantially the same requests from different programs on different schedules, formatted differently, routed to different repositories.

The correct architecture reverses the direction entirely:

Business risk → security objective → canonical enterprise control → implementation → authoritative evidence

Then, mapped outward from that foundation:

Enterprise control → NIST / ISO 27001 / SOC 2 / PCI DSS / SOX / internal policy / contractual obligations

The direction of the mapping matters. The conventional model starts with an external requirement and builds inward. The proposed architecture starts with operational reality and maps outward to the obligations that inspect it. Frameworks describe which requirements a given enterprise control satisfies. They do not generate controls.

A Crosswalk Can Document Duplication Without Eliminating It

The common response to compliance proliferation is the crosswalk: a spreadsheet mapping Framework A requirements to Framework B requirements, identifying where language overlaps. Crosswalks are useful reference documents. They are not a solution to the architectural problem.

The important relationship is not:

Framework A ↔ Framework B

It is:

Framework A → Actual Enterprise Control ← Framework B

Whether two frameworks use similar language is a secondary question. The operative question is whether the organization’s actual, implemented control satisfies both requirements given its specific scope, systems, and operational context. A crosswalk showing SOC 2 CC6.2 and ISO 27001 Annex A 5.18 addressing similar subject matter does not resolve whether the organization’s access provisioning process, as actually implemented, satisfies both. That determination requires examining the enterprise control.

A crosswalk can document duplication without eliminating it. Organizations that stop there find that they have produced an accurate map of framework relationships while leaving the underlying architectural problem untouched. The compliance programs remain separate. The evidence requests remain separate. The control owners remain burdened by substantially duplicative work, now accompanied by a spreadsheet that explains why the duplication is theoretically manageable. The problem is not that the frameworks have not been mapped to each other. The problem is that neither has been made subordinate to the control the company actually operates.

The Industry Already Has the Mapping Logic

The conceptual machinery for this architecture already exists. Each of the following examples demonstrates a different component of the thesis.

NIST’s National Online Informative References program provides a standardized way to express relationships between elements of different cybersecurity and privacy documents, including concept crosswalks, set-theory relationships, and supportive relationships. The important point is not the specific mapping taxonomy. It is that NIST treats relationships between requirements as something that can be explicitly modeled rather than implicitly assumed. Enterprises should apply that same discipline one level closer to reality: map external requirements to the controls they actually operate, model the relationships explicitly, and govern evidence accordingly.

The Secure Controls Framework, an independent open-source metaframework, maps over 1,500 controls across 34 domains against more than 200 cybersecurity and data privacy laws, regulations, and frameworks, including NIST CSF 2.0, SP 800-53, ISO 27001, SOC 2, PCI DSS, HIPAA, SOX, and GDPR. Its Set Theory Relationship Mapping methodology formalizes whether a given control satisfies a given requirement using a mathematically structured approach rather than subjective crosswalks. The explicit premise is that many external obligations can be normalized against a common control structure, eliminating the need to maintain separate control sets for each framework. The SCF is a reference point, not the complete proposal here. The argument is that organizations should build their own canonical operational architecture on the same underlying logic: implement controls once against the risks that matter, and map the obligations that inspect those controls.

The Cloud Security Alliance’s Cloud Controls Matrix demonstrates how a common control structure can map to multiple frameworks while explicitly preserving differences. CCM v4.1 contains 207 controls across 17 domains with mappings to major standards and frameworks including ISO, NIST, PCI DSS, CIS, and others. The significance is that a single CCM control can be mapped against multiple external requirements without assuming those requirements are identical. The mapping then exposes where that common control is sufficient and where additional work remains. CSA’s published framework mappings explicitly characterize relationships as reflecting no gap, partial gap, or full gap relative to each mapped standard — a structured analysis of where one control satisfies an external obligation and where it does not.

All three point toward the same architectural idea: preserve the differences between external requirements, but normalize their relationship to a common control structure. The missing step for most enterprises is making their own operational control environment that common structure.

One Access Review, Three Frameworks

Under PCI DSS v4.0, Requirement 7.2.4 mandates that all user accounts and related access privileges, including third-party and vendor accounts, be reviewed at least once every six months for systems within the cardholder data environment. ISO 27001:2022, Annex A control 5.18, requires access rights be reviewed at planned intervals with documented evidence of each cycle, leaving frequency to the organization’s risk assessment. NIST SP 800-53 Rev 5, control AC-2, addresses account management including periodic review, with frequency parameters tied to system risk classification rather than a fixed calendar interval.

These three requirements address the same operational control: review who has access, confirm it remains appropriate, document the result, remediate what is not. They differ in scope specification, prescribed frequency, documentation requirements, and rigor of definition.

An organization subject to all three does not have three access review controls. It has one access review program. The enterprise control governing that program should incorporate the most demanding applicable requirement along each dimension. The PCI DSS semiannual frequency applies to cardholder-environment accounts. NIST risk-classification logic governs frequency for populations outside that scope. Where ISO 27001:2022 requires documented evidence of each review cycle, that characteristic becomes a requirement of the enterprise control across all applicable populations.

The enterprise control that results is a composite — not one framework’s control applied verbatim to every population, but the control that satisfies all applicable requirements by incorporating the most demanding applicable element along each dimension.

This is what it means for frameworks to become views of the control environment. PCI sees the cardholder-environment accounts and the semiannual cadence. ISO sees the implementation and documented evidence. NIST sees the control through its risk-classification requirements. The underlying operational control does not multiply simply because the number of interested frameworks does.

The Strongest Applicable Requirement Wins, But Only Where It Applies

The access review example introduces a principle that extends across all overlapping controls: where multiple applicable requirements govern the same control objective, the enterprise control should adopt the most demanding applicable requirement along each relevant dimension. Where different frameworks impose stronger requirements along different dimensions, the result is a composite control.

“Most demanding” is multidimensional. Requirements differ by scope, frequency, evidence retention, authorization thresholds, testing methodology, technical implementation specificity, and assurance expectations. An enterprise control that adopts the highest frequency from one framework, the broadest scope from another, and the most rigorous documentation standard from a third is not compliance excess. It is the defensible, internally consistent approach to an environment where multiple obligations genuinely apply.

The principle is not: find the harshest requirement and impose it everywhere. It is: for a genuinely overlapping population, objective, and requirement dimension, design the enterprise control to satisfy the most demanding applicable obligation. When a population is subject to quarterly access reviews under one obligation, semiannual under a second, and annual under a third, one quarterly cycle satisfies all three. The enterprise control reflects the quarterly cadence. The compliance mapping records that the less frequent obligations are satisfied by a control operating at higher frequency. The evidence from the quarterly review supports all three assurance obligations without separate collection.

A control element that is maximally rigorous in one dimension may be unnecessarily burdensome in another. The goal is to ensure that the enterprise control, as designed and operated, meets or exceeds every applicable requirement along the dimensions that matter to each obligation, applied to the populations and systems where that obligation applies. The framework mappings preserve which obligation drove each element of the control; the enterprise control prevents those obligations from becoming separate operational processes.

Evidence Belongs to the Control

Controls generate evidence. Frameworks consume it. Mappings determine whether that evidence is sufficient.

That sequence is the economic argument for canonical enterprise controls. Evidence belongs to the operational control that generated it, not to the framework requesting it. If a quarterly access review is properly scoped, properly documented, and properly remediated, the evidence it produces is authoritative. A SOC 2 auditor can inspect it. A PCI QSA can inspect it. Internal Audit can inspect it. ISO 27001 certification auditors can inspect it. The access review happened once. Multiple parties inspecting that evidence does not transform it into multiple operational controls.

The fragmented compliance architecture treats each inspection as a separate request for separate evidence. Two management metrics could make the resulting overhead visible.

The first is what might be called a Compliance Duplication Ratio: substantially duplicative evidence requests across assurance activities divided by the unique underlying control-evidence events those requests represent. Suppose 800 assurance requests ultimately relate to 200 unique control-evidence events after legitimate differences in period, population, sample, and scope are removed. The resulting ratio is 4:1 — the compliance architecture is generating, on average, four separate requests for each control-evidence event the organization actually produces. The metric requires normalization for legitimate differences; a high ratio is a signal worth investigating, not an automatic indictment.

The second is an Evidence Reuse Rate: the percentage of authoritative control evidence successfully reused across applicable assurance obligations rather than separately recollected. An organization that reuses 80 percent of its access review evidence across its SOC 2, ISO, PCI, and internal audit processes has an 80 percent reuse rate for that control. An organization recollecting substantially the same evidence for each compliance process separately has a reuse rate approaching zero.

These are proposed management concepts, not established industry metrics. Their value is in directing attention toward a category of GRC cost that conventional compliance dashboards rarely surface. The objective is not merely to improve those ratios. It is to reveal where the organization is still treating frameworks as separate control environments rather than views of the same controls.

“But the Frameworks Aren’t Identical”

They are not. That is correct, and it is not a counterargument to the architecture proposed here.

The mapping architecture exists precisely because frameworks are not identical. If they were identical, no mapping would be necessary. The architecture requires that each mapping determination answer a specific question: given the organization’s actual control, as implemented and operated, does it satisfy this particular requirement, for this particular population, over this particular period?

That determination will produce one of three conclusions. Evidence is fully reusable when the control objective, implementation, scope, examination period, and evidence format satisfy both obligations and no additional work is required. Evidence is partially reusable when the underlying control activity and evidence are relevant to both obligations but one requires additional scope, a different testing approach, supplementary documentation, or a different frequency. Framework-specific evidence is required when the obligation addresses something the enterprise control does not cover.

The objective is to eliminate work whose only justification is that two frameworks gave different names to substantially the same operational reality. Once those differences are represented in the mappings rather than hidden inside separate control libraries, adding another framework becomes a mapping problem before it becomes an implementation problem.

A New Framework Should Trigger Mapping Before Control Building

Under the conventional model, a new or substantially revised framework triggers a new compliance program: scope assessment, gap analysis, control construction, evidence workflow design, testing design, and ongoing maintenance. The question asked is: “What do we have to build for this framework?”

Under the proposed architecture, the question is: “What does this framework require that our existing control environment does not already provide?”

The operating sequence:

New requirement → map to canonical controls → identify full coverage → identify partial coverage → identify genuine gaps → remediate only the gaps

A new framework should trigger a mapping exercise before it triggers a control-building exercise. Where existing controls meet new requirements, the mapping records that coverage. Where they partially meet requirements, the mapping identifies the gaps and new controls govern only what is genuinely missing. The answer to an auditor’s question about how the organization addressed a specific requirement should be grounded in the operational control, not in a compliance program constructed to satisfy the framework from the outside in. Only the genuine delta should be allowed to change the enterprise control environment.

Don’t Automate the Duplication

The GRC automation market is advancing rapidly. Continuous compliance platforms, AI-assisted evidence collection, automated control testing, and intelligent framework mapping tools are attracting significant investment, and some are producing genuine operational improvements.

These technologies can be valuable. The caution is about sequencing.

If an organization routes the same evidence request through five separate compliance processes because five programs independently represent the same control, automating all five requests does not fix the underlying problem. It makes the underlying problem faster. The Compliance Duplication Ratio remains unchanged. The control owner still receives five requests, arriving more quickly and logged more efficiently, but the architectural defect that produced them is intact.

Canonicalize first. Map second. Automate third.

Do not use increasingly sophisticated technology to automate compliance work that should not exist.

How to Build the Model

The following sequence implements the thesis directly for organizations that already have multiple compliance programs, existing audit relationships, and accumulated technical debt in the control library.

Inventory reality. Inventory controls based on what the organization actually does, not which framework currently names them. The question is not “what does our SOC 2 control library say?” It is “what does our organization actually do to manage access, protect data, monitor systems, respond to incidents, and govern vendors?”

Collapse duplicate representations. Identify controls that represent the same operational objective, implementation, population, and activity. Apply a decision gate before merging any two: Do they share the same objective? The same underlying control activity? The same implementation pattern? Overlapping populations? Compatible evidence? Where those answers point to the same operational control, canonicalize it and preserve scope-specific differences in the mapping or implementation detail. Where they reveal genuinely different control activities, preserve separate controls.

Canonicalize. Give each genuine enterprise control one authoritative definition, one designated owner, one implementation description, a defined scope, a defined testing method, and one authoritative evidence source.

Map inward. Map NIST, ISO 27001, SOC 2, PCI DSS, SOX, internal policies, and contractual requirements to the canonical controls. For each external requirement, identify which enterprise control it maps to, what classification that mapping produces, and what, if anything, needs to be adjusted or supplemented.

Apply the most demanding applicable requirement. Where requirements genuinely overlap, make the enterprise control satisfy the most demanding applicable requirement along each relevant dimension. Use composite controls where different frameworks impose stronger requirements along different dimensions, and document the composite explicitly.

Classify evidence. For every mapped obligation, determine whether the authoritative evidence is fully reusable, partially reusable, or framework-specific. Evidence that is fully reusable should be stored in a single authoritative location and referenced, not recollected, by each compliance process.

Measure duplication. Track redundant evidence requests and evidence reuse so compliance overhead becomes visible. Track the Compliance Duplication Ratio and the Evidence Reuse Rate as ongoing management metrics.

Automate last. Only after rationalization should automation accelerate the remaining control, testing, mapping, and evidence processes. Automation is a force multiplier. Apply it to a well-structured environment.

Conclusion

Return to the IAM team from the beginning. One access review occurred. It had one owner, one defined population, one result, and one authoritative body of evidence. PCI, SOC 2, ISO 27001, Internal Audit, and customers may each have legitimate reasons to inspect different aspects of it. Their interest does not transform one operational control into five.

Start with one control family. Access governance is a reasonable candidate. Inventory every version of the access review control that exists across your compliance programs. Identify the actual operational control underneath all of them. Establish the canonical version. Map each applicable requirement inward. Classify which evidence is fully reusable, which requires supplemental work, and which addresses something genuinely distinct. Count how many duplicate requests disappear. Then move to the next control family.

The company does not secure itself by operating SOC 2, ISO 27001, or NIST. It secures itself through access management, change management, vulnerability management, incident response, vendor governance, data protection, and other real controls. The frameworks tell the organization, its auditors, its customers, and its regulators what those controls must demonstrate.

The operating model is one enterprise control environment with many compliance views: controls generate the evidence, frameworks consume it, and the mappings preserve the differences.

The mature GRC organization will not become exceptionally efficient at proving the same thing five times. It will build one defensible control environment, map every obligation to it, and perform additional compliance work only where the requirements genuinely demand something more.

About the Author

Kimly Hong is a Principal Cybersecurity and GRC Consultant with more than ten years of experience building enterprise security programs across regulated financial services, hospitality, and technology environments. Her work spans governance, risk, and compliance program design, third-party risk management, access governance, and incident response readiness. She has built these programs from the ground up across complex, multi-region environments and currently consults across financial services, SaaS, and retail organizations. Connect on LinkedIn to continue the conversation.