Mapping one policy set to several frameworks without rewriting it

A common pattern: a company writes a policy set for ISO 27001, then a customer asks for SOC 2 and someone buys a second template pack, then PCI DSS arrives with its own requirements. Three overlapping policy sets, each slightly out of date, none matching what people actually do. Policies don't need to be framework-specific. They need to be organisation-specific, and mapped.

Structure: three layers

1. One information security policy: short, approved by leadership, stating objectives, scope, responsibilities and commitment. ISO 27001 clause 5.2 and PCI DSS 12.1.1 both require it.
2. Topic policies (a dozen or so): access control, acceptable use, asset management, cryptography, incident response, business continuity, supplier security, secure development, vulnerability and patch management, logging and monitoring, physical security, HR security.
3. Procedures and standards underneath, where the frequencies, settings and steps live. These change more often and shouldn't need leadership sign-off each time.

Put framework-specific detail in procedures, not policies: "access is reviewed every six months" belongs in the access review procedure, where PCI DSS's frequency can live without bloating the policy.

Map, don't rewrite

Keep a mapping table: one row per policy section, with the requirements it addresses in each framework. The Governance Policy topic shows what each framework expects at the top level:

Framework	Governance Policy	Link
NIST CSF 2.0	GV.PO-01GV.PO-02	Topic definition
ISO 27001	A.5.1A.5.37Clause 5.2	Crosswalk
CIS v8.1	—	No mapping in our data
SOC 2	CC5.3CC1.1	Editorial
PCI DSS	12.1.112.1.2	Crosswalk
CMMC	—	No mapping in our data
800-53	PM-1PL-1	Crosswalk
HIPAA	§164.316(a)§164.316(b)(2)(iii)	Crosswalk
GDPR	Art.24(2)	Editorial
NIS2	1.1	Crosswalk
Essential Eight	—	No mapping in our data

Full detail and the reason for every link: Governance Policy across frameworks →

When a new framework arrives, run a gap analysis and look at the governance and policy requirements: most will map to a policy you already have; the rest become new sections or procedures.

What frameworks specifically require in writing

• ISO 27001: an information security policy (5.2) and topic-specific policies as needed (A.5.1), communicated and reviewed.
• SOC 2: policies that establish what is expected, deployed through procedures (CC5.3).
• PCI DSS: for each of its twelve requirements, documented, current policies and procedures (x.1.1) and assigned roles (x.1.2), reviewed at least annually.
• NIS2: a policy on the security of network and information systems and topic-specific policies (Implementing Regulation point 1).
• NIST CSF 2.0: policy is established, communicated and enforced (GV.PO).

A minimal policy set

For most small and mid-sized organisations, these documents cover the policy requirements of ISO 27001, SOC 2, NIST CSF, PCI DSS and NIS2:

1. Information security policy (top level, approved by leadership)
2. Acceptable use policy
3. Access control policy
4. Asset management and data classification policy
5. Cryptography policy
6. Secure development and change management policy
7. Vulnerability and patch management policy
8. Logging and monitoring policy
9. Incident response policy (with reporting obligations)
10. Business continuity and backup policy
11. Supplier security policy
12. Human resources security policy
13. Physical security policy

Thirteen documents, most of them a few pages long, each with an owner and a review date. Procedures carry the detail and change more often.

Key takeaways

• Policies should be organisation-specific and mapped, not framework-specific.
• Put frequencies and settings in procedures.
• Thirteen short policies cover most frameworks.
• PCI DSS requires its policies and procedures to be reviewed at least annually.

Keep them true

• Write what you do, not what a template says. Auditors test policies against practice.
• Review annually, and after significant change, with a recorded approval.
• Short beats complete: a two-page access control policy people read is better than twenty pages nobody does.

For a full common control set built on the same idea, see one control set for SOC 2 and ISO 27001.

Questions

How many security policies do you need?

Fewer than most templates suggest. A top-level information security policy plus a dozen or so topic policies (access, acceptable use, incident response, supplier security and so on) usually covers ISO 27001, SOC 2, NIST and PCI DSS.

Does PCI DSS require specific policies?

Yes. Each PCI DSS requirement starts with a requirement for documented, current policies and procedures for that area (x.1.1), plus roles and responsibilities (x.1.2).