Compliance vs. Security: Finding the Nuance in the Wake of TeamPCP

Compliance vs Security

Fight! fight! fight!

A common topic of conversation in cyber security is the disharmony between two of the largest scopes of work security teams face day-to-day: those old chestnuts, compliance and security – or more accurately, “compliance versus security”. A common and very obvious take is that “compliance does not mean actual security outcomes”, and that time spent gaining these certifications is misaligned with actual organisational risk – and perhaps even a total waste of time. 

Well, is this the case or not? I decided to sit down and write a bit of a pro-compliance rebuttal piece to this opinion, but the situation is ultimately nuanced.

Compliance as a Trust Framework and Business Driver

Compliance is a way for organisations to trust each other. Frameworks such as ISO27001, SOC2, PCI-DSS and others provide a standard framework for knowing whether security controls have actually been implemented. Businesses often won’t buy from vendors they can’t trust; for a B2B organisation, this affects the bottom line. This makes compliance one of the strongest levers a security team can pull to secure the budget for necessary controls. At SEP2, we view our own Security Accreditations including our ISO 27001 certification and CREST-accredited SOC, not just as badges, but as the baseline for the trust our customers place in us. Likewise, a public sector organisation will have legal statutes that they have to adhere to in order to be viewed as a trustworthy custodian of public services, which requires a budget to maintain.

When Trust Fails (The Auditor Problem)

To paint a picture, I’m writing this having scratched my head trying to parse recent claims that third-party auditors aligned with the compliance platform Delve allegedly falsified a large number of SOC2 audit reports for Delve’s customers. If this is indeed what has happened, this brings the auditors into a potentially legally difficult position, as the report is designed to be an “attestation” of controls that the customers of their customers rely on them maintaining, either at a point in time or over a monitored period. Given that SOC2 is the logical answer to the question, “How do I know for sure that you have implemented the controls you claim to have implemented?”, a failure in the trust process is a massive own-goal for “Team Compliance.” (if you will afford me using an oversimplistic analogy here).

For what it’s worth, I’ve seen organisations put through the wringer by auditors, but also seen things that are blindingly obvious issues go un-noticed, or unsaid.

It is ultimately incumbent on the bodies that provide these key security certifications to ensure that organisations who are certifying and attesting these are held to the highest possible standards.

How Compliance Drives Positive Security Outcomes

On the flip side, there is the fact that introducing compliance is going to do some positive things to an organisation from a security standpoint. If a leadership team approves the implementation of ISO27001, as an example, they are committing to a budget for a set of controls that might have previously been out of reach for the organisation. 

Without deliberability misinterpreting the standard, there is an opportunity here for security teams to get access to tools, resources and maybe additional headcount that also help them achieve some of their technical backlog. There is also the simple matter of discipline: if an auditor tells you that you need to perform an account review every 90 days, there’s a good chance you weren’t doing it before. Now, that ex-contractor whose VPN account was left open for seven months is identified much faster.

Avoiding “Compliance Theatre” and Addressing Real-World Security Risks

There’s a balance to be struck, however. It is imperative that the security team’s time isn’t getting completely consumed with “busy work” of compliance at the expense of what they are seeing on the ground. Teams need the breathing room to pull on threads and see what unravels as part of the natural curiosity that I see day-to-day in security teams.

Sure, you might have a clean audit report, but if the failure to properly fund a DLP (Data Loss Prevention) tool leads to your sales database leaking, that “clean” report doesn’t matter much.

Managing Third-Party Risk

Getting to the meat of the situation now – which is why we use compliance to represent security posture – how do organisations ensure that their prospective and current suppliers are not opening them up to risk? 

The uncomfortable truth is that you often can’t. Statements can be misrepresented and backed by an endless lineage of fourth and fifth parties who may not have implemented the right controls. For example, the Trivy code vulnerability scanner has already faced its second major code compromise this year (March 2026), but very few organisations will be capturing this as a risk or known asset for themselves, let alone their third parties, or have the ability to ask their customers if they are affected. Tools such as RiskLedger might be moving the needle on this a bit, but still represent an incomplete picture and suffer from “marking of one’s own homework”. 

No compliance framework in the world will save you from the impact of something like a Trivy compromise unless you are doing the right things yourself. If you care about that level of security, you’ve got to make your own requirements based on a structured and systematic risk management approach that is aligned to your organisation’s objectives.

The Path Forward for Diligent Implementation

In summary, the picture is nuanced. The issue isn’t typically the frameworks themselves; it’s how seriously they are taken and how diligently they are implemented.

• If you’re just trying to pass an audit by resubmitting old evidence and misdirecting your auditor, you are doing little for your security posture and potentially more harm than good.
• If you take the standard seriously outside of the audit cycle – meaning the weeks leading up to the audit aren’t a mad rush to “replay” the last 12 months of tasks you neglected – then you are likely doing things right.

Ultimately, the traits that make security teams effective – restless dissatisfaction, a spark of creativity, and the willingness to be the “bad guy” in a conversation – are the same traits that make compliance work as a shield rather than just “theatre.”