The common core: security requirements every framework shares

Organisations rarely answer to one security framework. A software company sells to US customers who want a SOC 2 report and European customers who want ISO 27001; a payment provider adds PCI DSS; an EU digital provider now falls under NIS2. Each framework arrives with its own structure, numbering and vocabulary, and it is easy to conclude that each one means a separate programme.

They don't. Underneath the different numbering there is a lot of shared ground, and a small part of it is shared by every framework we map. We looked for the topics that have a mapped requirement in all eleven: NIST CSF 2.0, NIST SP 800-53, ISO 27001, CIS Controls, SOC 2, PCI DSS, CMMC Level 2, the HIPAA Security Rule, GDPR, NIS2 and ASD's Essential Eight.

The five topics in every framework

Topic	ISO 27001	SOC 2	PCI DSS	NIS2
Asset Management	A.5.9	CC6.1	12.5.1	12.4
Vulnerability Mgmt	A.8.8	CC7.1	6.3.1	6.5
Backup & Recovery	A.8.13	A1.2	9.4.1.1	4.2
Incident Response	A.5.24	CC7.4	12.10.1	3.1
Reporting	A.5.5	CC2.3	12.10.1	3.3

5 of 50 topics have a mapped requirement in all 11 frameworks. Each topic page lists every framework's requirement IDs and the evidence for each link.

That is the common core: asset management, vulnerability management, backup and recovery, incident response and incident reporting. Every one of the eleven frameworks has at least one requirement in each, even GDPR, which is a privacy law, and the Essential Eight, which is a short list of technical mitigations.

It is a short list on purpose. Many other topics, such as access control, logging and encryption, are covered by ten of the eleven, and most frameworks share far more than five topics. But these five are the ones no framework leaves out.

Why these five

They follow the life of an incident. You cannot protect what you don't know you have (asset management). Most attacks still exploit known weaknesses (vulnerability management). When something goes wrong you need to restore systems and data (backup and recovery), handle the incident (incident response) and tell the people who need to know: management, customers, regulators (incident reporting).

Frameworks disagree about almost everything else: whether governance is a management system or a set of outcomes, how prescriptive technical controls should be, how often things must happen. On these five they agree, because without them the rest doesn't work.

Same topic, different depth

A shared topic doesn't mean an identical requirement. Take vulnerability management:

Framework	Vulnerability Mgmt	Link
NIST CSF 2.0	ID.RA-01ID.RA-08	Topic definition
ISO 27001	A.8.8	Crosswalk
CIS v8.1	CIS 7.1CIS 7.2CIS 7.5CIS 7.6CIS 7.7CIS 16.6CIS 18.1CIS 18.2CIS 18.3CIS 18.4CIS 18.5	Crosswalk
SOC 2	CC7.1	Editorial
PCI DSS	6.3.111.3.111.3.2	Crosswalk
CMMC	RA.L2-3.11.2RA.L2-3.11.3	Crosswalk
800-53	RA-5CA-8	Crosswalk
HIPAA	§164.308(a)(1)(ii)(A)§164.308(a)(1)(ii)(B)§164.308(a)(8)	Crosswalk
GDPR	Art.32(1)(d)	Editorial
NIS2	6.56.10	Crosswalk
Essential Eight	ISM-1807ISM-1808ISM-1698ISM-1699ISM-1701ISM-1702	Editorial

Full detail and the reason for every link: Vulnerability Mgmt across frameworks →

ISO 27001's A.8.8 asks you to obtain information about technical vulnerabilities, evaluate your exposure and take appropriate measures, and leaves the timing to your risk assessment. PCI DSS requires internal scans every three months and after significant changes (11.3.1), external scans by an Approved Scanning Vendor (11.3.2), and critical and high-severity patches within a month of release (6.3.3). The Essential Eight sets patching deadlines that tighten at each maturity level. HIPAA reaches the topic through its risk analysis and risk management requirements rather than a vulnerability-specific one.

So the common core tells you what every framework expects you to do, not how much. When you build a control, design it to the strictest framework you answer to, and the others will usually follow.

What it looks like in practice

• Asset management: one inventory of hardware, software, cloud services and data stores, with owners, kept current by discovery tools rather than spreadsheets alone.
• Vulnerability management: scheduled scanning (internal and external), a severity rating, remediation deadlines by severity, and evidence that deadlines are met.
• Backup and recovery: backups of data, software and configuration, protected from change and deletion, with restores tested on a schedule.
• Incident response: a written plan with roles, severity levels and escalation, exercised at least once a year.
• Incident reporting: a procedure that says who must be told, within what time, by whom: internal management, customers under contract, and regulators (for example, the NIS2 24-hour early warning or GDPR's 72-hour notification to the supervisory authority).

Why the core matters

If you are starting a security programme, build these five first. They are the requirements you will meet in every framework you might adopt later, so the work is never wasted.

If you already juggle several frameworks, use the core as the backbone of a common control set: one control for each of these topics, mapped to every framework you answer to, with evidence collected once. The same idea extends to the topics shared by ten, nine or eight frameworks. Our coverage matrix shows all fifty topics against all eleven frameworks, and the gap analysis shows, requirement by requirement, what carries over between any two.

How we measured it

Each topic in ControlMapping is defined by NIST CSF 2.0 outcomes, and lists the requirement in each framework that addresses it. A link is labelled crosswalk when a published crosswalk (from NIST, ENISA, CIS or PCI SSC) supports it, and editorial when it is our judgement, with the reason shown. SOC 2, GDPR and Essential Eight links are always editorial, because no openly licensed crosswalk exists for them. The full method is on the methodology page, and every number above comes from the live data, so it updates when the mappings change.

Questions

Which security controls are required by every framework?

In ControlMapping's data, five topics have a mapped requirement in all 11 frameworks: asset management, vulnerability management, backup and recovery, incident response, and incident reporting. The exact wording and depth differ by framework.

Does meeting one framework's version satisfy the others?

Not automatically. A mapping means the requirements address the same topic; one may be far more specific (PCI DSS and the Essential Eight set deadlines and frequencies that ISO 27001 leaves to you). Check each framework's text.