Control Mapping

A company is told three enterprise deals need SOC 2, ISO 27001 and PCI DSS. Treating them as three projects means three sets of policies, three evidence collections and three audit seasons for questions that overlap heavily: who has access to production, how changes are approved, how incidents are handled. Control mapping defines each control once, in the company's own words, and records which framework requirements it satisfies.

Why it matters

Frameworks differ in scope and wording, not in the underlying security hygiene: access control, change management, logging and monitoring, vulnerability management, vendor risk and incident response appear in all three. A common control set typically covers most of each framework's requirements, and the remainder is framework-specific work (PCI's cardholder environment scoping, ISO 27001's management system and risk treatment). The effort drops from sum to roughly union.

Implementation patterns

• Write controls as testable statements: "Production access requires SSO, MFA and approval, and is reviewed quarterly," with an owner and an evidence source.
• Map to each framework's identifiers (SOC 2 Trust Services Criteria such as CC6, ISO 27001 Annex A controls, PCI DSS requirements) in a table or a compliance platform.
• Automate evidence collection from systems of record: identity provider exports, change records from the pipeline, vulnerability scan results.
• Reduce scope first: isolating cardholder data, or using a hosted payment field, cuts the systems under assessment before any control is written.
• Own the mapping: one named person maintains it, and control changes update every mapped requirement.
• Test operation, not existence: sample the control's evidence each month, because auditors sample across the period.

Industry example

The mapping is a documented practice: NIST's Cybersecurity Framework publishes informative references that map its categories to ISO 27001 and other standards, and the AICPA has published mappings of the SOC 2 Trust Services Criteria to other frameworks. This is the practice behind compliance platforms that sell pre-mapped control libraries. No individual company's mapping is cited here.

Failure scenarios

• Paper controls: policies exist but nobody performs them; the audit samples a quarter and finds gaps.
• Evidence by screenshot, assembled in a sprint before the audit, which fails when asked for a population over time.
• Over-broad scope: every system in scope because boundaries were never drawn, multiplying cost.
• Mapping drift: a control changes and the mapped requirement no longer holds.
• Treating the certificate as security: passing an audit while real weaknesses remain, a gap compliance reviews repeatedly find.

Trade-offs

When not to use it

A company with one framework requirement and a small system does not need a mapping layer; implement the framework directly. The pattern pays from the second framework onward.

Interview question

Q: You must satisfy SOC 2, ISO 27001 and PCI DSS within a year. How do you structure the work?

What a strong answer covers: scoping first; a common control set; the overlap and the framework-specific remainder; observation-period timing for SOC 2 Type II; automated evidence; owners and budget; and building controls into pull requests and access reviews so compliance is continuous.

Quick check

Quiz: What is the first step that most reduces PCI effort? Reducing the number of systems that touch cardholder data.

Flashcard: What does a control map avoid? — Collecting the same evidence three times for three audits.