The security topics the fewest frameworks require, and why that matters

A security programme built only from compliance requirements tends to be strongest where frameworks agree and weakest where they're silent. We ranked all fifty ControlMapping topics by how many of the eleven frameworks map a requirement to them. The bottom of that list is where a framework-led programme is most likely to have blind spots.

The least-required topics

Topic	Mapped in	No mapping in
DNS Security	4 of 11	SOC 2, PCI DSS, CMMC, HIPAA, GDPR, NIS2, Essential Eight
API Security	5 of 11	SOC 2, CMMC, HIPAA, GDPR, NIS2, Essential Eight
Business Environment	5 of 11	CIS v8.1, CMMC, HIPAA, GDPR, NIS2, Essential Eight
Threat Intelligence	5 of 11	CIS v8.1, SOC 2, HIPAA, GDPR, NIS2, Essential Eight
WAF	6 of 11	CMMC, HIPAA, GDPR, NIS2, Essential Eight
Communication	7 of 11	PCI DSS, HIPAA, GDPR, Essential Eight
Forensics	7 of 11	CIS v8.1, HIPAA, GDPR, Essential Eight
Mobile Security	7 of 11	PCI DSS, GDPR, NIS2, Essential Eight
Web Security	7 of 11	HIPAA, GDPR, NIS2, Essential Eight
Business Continuity	8 of 11	CIS v8.1, CMMC, Essential Eight

Why these topics are missing

Frameworks are written at a level above the technology. ISO 27001, SOC 2 and GDPR describe outcomes ("protect information in networks", "secure development") that apply to any technology, so they rarely name DNS, APIs or web application firewalls. Those topics are covered implicitly, through broad controls, if your risk assessment brings them in.

Frameworks lag the threat landscape. Many were drafted when the perimeter was a firewall and applications were installed software. APIs, cloud-hosted web applications and DNS abuse became common attack paths faster than standards were revised. ISO 27001:2022 added threat intelligence and web filtering as new controls; CSF 2.0 strengthened supply chain and platform security. Others haven't caught up.

Some topics are context, not controls. "Business environment" (understanding your mission, stakeholders and dependencies) is governance groundwork. Frameworks assume it rather than require it.

Why it matters

Attackers don't read frameworks. Some of the least-required topics are among the most exploited in practice: exposed APIs, vulnerable web applications and DNS manipulation. A programme that implements only what auditors ask for can pass every audit and still leave these open.

The topics at the bottom of the list are where your own risk assessment has to do the work that the frameworks don't.

Key takeaways

• DNS security, threat intelligence, API security and web application protection are required by the fewest frameworks we map.
• That's mostly because frameworks are written above the technology and revised slowly, not because these topics matter less.
• Several of the least-required topics are among the most exploited attack paths in practice.
• Your own risk assessment has to cover what frameworks leave out, and a reasoned decision should be recorded either way.

What to do

• Check the bottom of the list against your own attack surface. If you run public APIs or web applications, API security and web security matter regardless of what your frameworks say.
• Use the most specific framework that covers a topic as your standard, even if you aren't certified against it. The CIS Controls and PCI DSS are often more specific than ISO 27001 on technical topics; the topic pages show who requires what.
• Record the decision. If your risk assessment concludes a topic doesn't apply, write down why. Auditors accept a reasoned exclusion; attackers don't care either way.

The coverage matrix shows all fifty topics against all eleven frameworks at a glance. For the opposite end of the list, see the topics every framework shares.

Questions

Which security topics do the fewest frameworks require?

In ControlMapping's data, DNS security, threat intelligence, API security, business environment and web application firewalls are mapped in the fewest of 11 frameworks.

If a framework doesn't require a control, can I skip it?

Compliance-wise, perhaps; security-wise, rarely. Most frameworks are risk-based, so a missing topic usually means 'covered by your risk assessment', not 'unnecessary'.

Which framework covers API security best?

None covers it comprehensively. The CIS Controls' application software security control and PCI DSS's secure development and public-facing web application requirements are among the most specific; OWASP's API Security Top 10 is the usual technical reference.