Compliance Gets You a Certificate. Risk-Based Security Keeps You Secure. Here Is Why Your Organisation Needs Both

In 2013, Target Corporation, one of the largest retailers in the United States suffered one of the most significant retail data breaches in history. Forty million payment card records were stolen. The breach cost Target an estimated 162 million dollars in direct costs and contributed to the resignation of its CEO and CIO.

Target was PCI DSS compliant at the time of the breach.

This is not a rare coincidence. It is a pattern. Organisations achieve compliance sometimes at enormous cost and effort and then suffer significant security incidents that the compliance framework they passed did not prevent. Marriott International was GDPR-compliant when it disclosed a breach affecting 500 million guest records in 2018. British Airways was ISO 27001 certified when it suffered a breach that resulted in a 20 million pound ICO fine in 2020.

Compliance frameworks are not designed to prevent breaches. They are designed to establish minimum standards of practice. Understanding this distinction and acting on it is the difference between a security programme that looks good on paper and one that protects the organisation.

What compliance frameworks do

Before making the case for risk-based security, it is important to be precise about what compliance frameworks achieve because they achieve a great deal.

ISO 27001 provides a structured management system for information security. It requires organisations to identify their assets, assess the risks to those assets, implement controls, and continually improve. Achieving certification demonstrates that an organisation has a functioning information security management system that meets an internationally recognised standard. This has real value for procurement decisions, for regulatory relationships, for insurance purposes, and for customer trust.

UK GDPR and the Nigeria Data Protection Act 2023 establish legal obligations for how personal data is handled. Compliance with these frameworks is not optional, failure to comply carries material financial and reputational consequences. The ICO can fine organisations up to 17.5 million pounds or four percent of global annual turnover. The Nigeria Data Protection Commission has equivalent enforcement powers.

NIST CSF provides a comprehensive framework for understanding and improving cybersecurity risk management. Its five functions of Identify, Protect, Detect, Respond, Recover give security teams a structured language for discussing and improving their security posture.

These frameworks are valuable. The problem is not the frameworks. The problem is what happens when compliance with the framework becomes the goal rather than the means.

The compliance trap

When compliance becomes the goal, organisations optimise for audit performance rather than security outcomes. Organisations implement controls because the framework requires them, not because they address the most significant risks the organisation faces. Effort concentrates on the areas auditors examine and disperses from the areas they do not.

This creates a predictable failure mode. The organisation's documented controls satisfy the auditor. The organisation's actual security posture may be quite different from what the documentation describes.

Consider how this plays out in practice. An organisation pursuing ISO 27001 certification conducts a risk assessment, a genuine requirement of the standard. But under compliance pressure the risk assessment is conducted quickly, at a high level, using a methodology designed to produce acceptable outputs rather than accurate ones. Teams rate risks moderate across the board to avoid triggering control requirements that would be expensive to implement. The assessment satisfies the auditor. It does not reflect the organisation's actual risk landscape.

Or consider the common practice of implementing controls to address framework requirements without first asking whether those controls address the organisation's most significant actual threats. An organisation might invest heavily in physical security controls because they appear in Annex A of ISO 27001, while underinvesting in cloud security controls because cloud infrastructure was not prominent when the organisation's security programme was designed. The framework is satisfied. The organisation's biggest actual risk, its cloud environment is under-protected.

The Target breach illustrates this failure mode precisely. Target was PCI DSS compliant, meaning its payment card processing environment met the standard's requirements. But the attackers did not enter through the payment processing environment. They entered through an HVAC contractor's credentials, moved laterally through Target's network, and reached the payment systems from inside. PCI DSS did not require Target to assess or control the risk posed by third-party vendor access to internal systems in the way that would have prevented this attack. So Target did not. The compliance framework was satisfied. The risk was not managed.

What risk-based security looks like

A risk-based approach to security starts with a different question. Not "what does the framework require?" but "what are the most significant threats to our organisation, and what controls would most effectively reduce the risk they pose?"

This sounds obvious. In practice it requires a genuinely different methodology.

The starting point is threat intelligence. What types of attacks are most commonly used against organisations in your sector, your geography, and your technology profile? For a Nigerian fintech, the threat landscape looks different from a UK professional services firm. Business email compromise, SIM swap fraud, and insider threats are prominent in Nigerian financial services. Ransomware, supply chain attacks, and advanced persistent threats are prominent concerns for UK enterprise. A risk-based programme is calibrated to the actual threats the organisation faces, not a generic threat landscape.

The second step is understanding your actual attack surface. Not the attack surface described in a risk assessment document, but the actual current state of your environment. What internet facing assets do you have? What third-party access exists to your internal systems? What cloud services are in use including those adopted by individual teams without formal IT approval? What credentials exist that could be compromised?

The third step is honest prioritisation. Given your threat landscape and your actual attack surface, where are you most likely to suffer a significant incident? What controls would most reduce that likelihood? What controls would most reduce the impact if an incident occurs despite your preventive measures?

This prioritisation is where risk-based security diverges most sharply from compliance-based security. A compliance framework distributes control requirements broadly. You must implement controls across all fourteen domains of ISO 27001, for example. Risk-based security concentrates effort where the risk is highest. It may mean implementing significantly stronger controls in three or four high-risk areas than the framework requires, while implementing baseline controls in lower-risk areas. The overall security posture is better. The compliance score may not be higher.

NIST CSF as a risk-based framework

The NIST Cybersecurity Framework is designed from the ground up as a risk-based tool rather than a compliance checklist. Its current iteration NIST CSF 2.0, published in 2024 is built around six functions: Govern, Identify, Protect, Detect, Respond, and Recover.

The Govern function which is new in version 2.0 sits above the others and emphasises that cybersecurity risk management must be integrated into the organisation's overall risk management approach. This is a critical design principle. It means that cybersecurity decisions are made in the context of the organisation's strategic objectives, risk appetite, and business model, not in isolation from them.

Using NIST CSF as a risk management tool means using the framework's outcome statements as a lens through which to assess your current state and identify your most significant gaps, then prioritising improvement based on risk rather than framework completeness. An organisation in the early stages of security maturity might achieve Tier 1 (Partial) in most areas of the framework while achieving Tier 3 (Repeatable) in the two or three areas that address their most significant actual risks. This is a better security posture than Tier 2 (Risk Informed) uniformly across all areas, because it concentrates protection where it matters most.

The case for both in the right order

The argument here is not that compliance frameworks are worthless. They are not. The argument is about sequencing and orientation.

Risk-based thinking should come first. Start with a genuine, honest assessment of the threats your organisation faces, the assets most critical to your operations, and the controls that would most reduce your actual risk. Design your security programme around those answers.

Compliance frameworks should come second as a check and an amplifier. Once you have a risk-based programme, use compliance frameworks to identify controls you may have missed, to demonstrate your programme's maturity to external stakeholders, and to satisfy the regulatory obligations that apply to your sector and geography.

This sequencing produces a security programme that genuinely protects the organisation and achieves compliance as a natural output. The reverse sequencing compliance first, risk second produces a programme that achieves compliance and may or may not protect the organisation.

For UK enterprises the practical application of this is to use NIST CSF or the NCSC Cyber Assessment Framework as the primary risk management tool, with ISO 27001 and UK GDPR compliance as requirements layered on top of a risk-based foundation. For Nigerian enterprises, the CBN Cybersecurity Framework and NDPA 2023 set the compliance floor, with risk-based thinking providing the structure above it.

A conversation worth having with your board

The practical implication of this argument is a conversation that many security leaders find uncomfortable: telling the board that being compliant is not the same as being secure, and that the security investment required to manage the organisation's risks may be different from and in some cases greater than the investment required to maintain compliance.

This is a conversation worth having. Boards are increasingly capable of understanding the distinction. High-profile breaches of compliant organisations have made the point in the most expensive possible way. Regulators in both the UK and Nigeria are increasingly clear that compliance is a floor, not a ceiling.

The organisations that handle this conversation well are the ones that arrive at the board with a clear picture of their actual risk landscape, a coherent programme designed around that picture, and compliance achievements that demonstrate the programme's rigour rather than substitute for it.

FortressPoint works with organisations across UK and Nigerian markets to design security programmes that start with risk and use compliance frameworks as the structure through which risk management is demonstrated and validated. If your security programme was designed around a compliance checklist, it may be delivering less protection and less value than it should.