Skip to content

Security is not Compliance

Some companies like to combine their Security and Compliance teams into one entity. I've worked in environments like that before, and I can tell you from experience that it is usually a bad idea to mix the two. Let's dig into it.

Security and Compliance?

Compliance is the practice of defining policies and standards, and would define WHAT controls need to be implemented. Security on the other hand would look at the HOW the controls are to be implemented, rooted in a risk-based approach where controls can be mitigated with other contols.

Ok, what does that mean? Compliance can be very black and white - something either is or isn't meeting a particular objective. Security on the other hand can have varying levels of meeting its objective. In that is where the first hurdle emerges. Compliance wants a team to be compliant against a certain standard, and security will (at times) struggle to meet that particular objective.

How compliance and security conflict

Let's work through an actual example - server patching. An organisation has a particular standard (or policy) that states all servers must be patched to the latest monthly patch that is publishes by the organisation. This patch would typically be a collection of all the latest patches published for that operating system in the last month. This is easy to measure - you simply look at your inventory of servers, and count the number of servers that are running the latest monthly patch.

Where Security sometimes struggle, is meeting that objective. While physically patching a server is (relatively) easy, getting an approved outage window is typically the biggest challenge. Servers run an important part of the back office, and rebooting or patching them at an odd time can cause serious business impact.

What about testing? We're a little outside the realm of security, yet when an update to an operating system causes an outage, because the new patch is incompatible with the business' application, the Security team is typically blamed for it.

The "Spirit" and the "Letter"

When dealing with these challenges, it is important to understand the differences between the "spirit of the rule" vs the "letter of the rule".

Compliance has a legalistic background - rules that need to be followed. Are these rules to be followed exactly as is, or are they guidelines to drive a specific behaviour? It really depends. Some frameworks are not forgiving, like PCI DSS - you either are (or are not) compliant to the rule. Others, like ISO27001 would allow for some flexibility in the interpretation of security controls.

Why is that important?

A compliance rule may specify that servers must be patched on a monthly cycle. A security mitigation plan may justify that while patching the server is not possible, the risk can be mitigated by loading an EDR tool, locking down firewall ports, or implementing a virtual patching solution.

If we're dealing with the "spirit of the rule", then these are valid mitigation strategies. If we're dealing with the letter of the rule, mitigation strategies are not a valid solution.

How we deal with it

You could argue that "risk" is at the center of it all. While there's a lot of truth in that, it's not always the case. While at the core it is risk based, there are compliance frameworks that are regulatory in nature. A payment provider will not have much of a choice with meeting PCI DSS compliance - it is an obligation they need to meet. When it comes to dealing with exceptions, it could become tricky.

When dealing with risk-based compliance, you have a few options.

  • Just do it - implement the control, just get it done.
  • Do it later - make sure your risk appetite support doing it later. A delayed mitigation is not necessarily a problem, however if the risk were to eventuate, you will need to explain what you could have done to prevent it.
  • Mitigating Controls can be implemented. If you're not able to put the required control in place, there may be other things you could do to reduce the risk.
  • Do nothing is a very risky option. If the potential impact is low, then accepting the risk is certainly a valid risk decision. Be careful not to simply go to risk acceptance when risk mitigation may seem a little challenging.

For regulatory (non-negiotable) compliance risks, your options start to diminosh.

  • Just do it - you don't have a choice. Get it done.
  • Do it later - You may need to do it later due to operational requirements. You may need to combine it with mitigating controls, to ensure you don't expose your environment, but do keep in mind that not all frameworks would allow a mitigating control as a valid exception for the objective.
  • Risk Removal - Can you decommission the solution? Removing the risky application is a good way to meeting the compliance.

What's next?

Security and compliance serve different but complementary purposes—compliance defines what must be done, while security determines how to do it based on risk. Conflicts often arise when compliance requires strict adherence, but operational realities limit how security teams can respond. Understanding the difference between the “letter” and the “spirit” of a rule is critical. In risk-based frameworks, alternative mitigations may be acceptable, but in regulatory environments, options are far more limited. Knowing when and how to apply each approach ensures both compliance and practical security can coexist effectively.