Why compliance and engineering keep talking past each other, and how to get them working on the same problem
There is a conversation that happens in security teams constantly, and it almost never goes anywhere useful.
A compliance professional raises a finding. An engineer responds with a technical explanation. The compliance professional restates the policy requirement. The engineer explains why the policy doesn't apply in this context. The compliance professional files the finding anyway. The engineer closes the ticket without changing anything meaningful. Both sides walk away frustrated, and the actual risk is unchanged.
This isn't a people problem. It's a framing problem. Compliance security and engineering security are optimizing for different things, measuring success differently, and often asking completely different questions, even when they're sitting in the same room looking at the same system.
Understanding why is the first step toward making the conversation productive for everyone involved.
Two Frames, One Problem
Compliance security asks: Does this meet the standard?
Engineering security asks: Does the standard actually address the threat?
These are not the same question. The gap between them is where a lot of organizational risk lives, unexamined.
Compliance exists for good reasons. Regulatory frameworks, audit requirements and industry standards create accountability. They give organizations a common baseline, defensible documentation and a shared vocabulary for talking about risk. Without them, security would be ad hoc, inconsistently applied and impossible to verify from the outside.
But frameworks are necessarily backward-looking. They codify what has gone wrong before and describe controls that were adequate when they were written. They measure whether a control is present, not whether it is effective against the threat your organization actually faces.
Engineering security works from the other direction. It starts with the system as it actually exists, not as it appears on a diagram, and asks what an attacker could do with it. It follows attack chains to their conclusion. It asks not just "is the control present" but "does the control change the outcome if an adversary is motivated and capable."
Neither frame is complete without the other. Compliance gives you coverage and accountability. Engineering gives you depth and realism. An application that doesn't fit the standard can still be secure in its own way, but "in its own way" has to be shown, not asserted. Hold that thought; it comes back below.
The Metric Is Not the Goal
The clearest symptom of the disconnect is how each group thinks about metrics.
Compliance tends to measure presence and frequency. Is the control documented? Is the scan running? Was the patch applied within the SLA window? These are measurable, auditable and reportable. They produce the dashboards leadership sees and the evidence packages auditors review.
Engineering tends to be skeptical of metrics for exactly the reasons compliance values them. A metric tells you whether something happened, not whether it mattered. A missed patching deadline could mean a planned maintenance window, a dependency conflict, or real exposure. The number doesn't say which. Chasing it without context produces a lot of activity and little improvement.
Metrics aren't useless. They're good for spotting trends, allocating resources and giving stakeholders a summary view. But one data point is noise, and a pattern over time is signal. The mistake is treating noise as signal because the reporting cadence demands an answer. Take for example a report that shows non-compliance with vulnerability management. Working to get details on why a given metric was missed in one month of a monthly metric offers little beyond kneejerk reactions to change the process. The real value is repeated misses and the percentage of those misses over multiple months, or even years and figuring out where those problems are.
Completion-rate metrics have the same problem. "X percent of findings remediated" measures activity, not outcome. A team that closes every low-severity informational finding while deferring one critical architectural exposure has a high completion rate and a serious unaddressed risk. The metric rewards closing tickets, not reducing exposure.
Scanner output makes this worse. Basic scanners flag vulnerabilities by version number, known pattern or configuration check, often without knowing whether the vulnerable code path is reachable from an external input, whether the application uses the affected function, or whether other controls make exploitation impractical. (Some newer tools do reachability analysis, which helps, but it isn't universal.) Many findings are theoretically valid and practically irrelevant. Closing them satisfies the metric without changing what an attacker can do, while the handwritten authentication logic three files over, which no scanner would surface, goes unexamined.
False positives compound it. When a large share of findings turn out to be invalid, the completion rate stops meaning anything: you're measuring how fast you can close things that shouldn't have been opened. Engineers learn that findings can't be trusted at face value and start treating all of them as noise. Remediation slows, not because anyone is negligent, but because the signal-to-noise ratio is too poor to prioritize. Compliance sees low completion and escalates. Engineering sees an unreliable queue and deprioritizes. Both are responding rationally to their own view, and the number gets chased while the risk goes unmanaged.
Both Sides Get It Wrong
It would be easy to read the above as "compliance is box-ticking and engineers know better". That isn't the whole picture, and it isn't fair.
Engineers are confident, and often right, when they say a finding doesn't apply. But "this doesn't apply" is a claim, and sometimes it's wrong. Imagine an engineer who dismisses a finding about an internal-only service because "nothing can reach it from outside", and a later review of the network configuration shows a forgotten rule exposing it. The standard that flagged it, however clumsily, was doing its job. Engineers can miss exposures they've stopped seeing, because they know the system too well to question it.
So the fix isn't "trust engineers over the standard". It's that the claim needs evidence the other side can check. That brings us to the part most articles skip.
The Missing Mechanism: Documented Risk Acceptance
The opening scene, finding filed and ticket closed with nothing changed, usually isn't an argument that needs winning. It's a missing process.
Most mature organizations resolve it with a formal exception or risk-acceptance path:
- State why the control doesn't apply or can't be met. Not "it's not a real vulnerability", but "the vulnerable function isn't reachable because of X".
- Name the compensating control. What is reducing the risk instead?
- Assign an owner. A named person signs that they accept the residual risk.
- Set a review date. Exceptions expire, so "not applicable today" gets re-checked.
This gives the engineer a way to say "this doesn't apply" in a form compliance can accept and an auditor can read. It gives compliance evidence instead of a verbal assurance. And it turns a stalemate into a record: if the reasoning turns out to be wrong, there's a named owner and a trail to learn from.
Without it, the only options are "comply" or "ignore", and both sides pick whichever suits them.
The Code Problem
There's a specific version of this disconnect: security reviewers who can't read code assessing systems built by engineers who don't always think about security.
Take the common practice of reviewing architecture diagrams. A compliance-trained reviewer can check whether required components are present: firewalls, encryption at rest, access controls. What they often can't see is what's missing from the diagram that would change the assessment: the authentication check that should be on every endpoint but isn't, the proxy that all cross-region traffic is supposed to go through, the setting that looks right on paper and is subtly wrong in the implementation.
An engineer reading the same diagram fills those gaps automatically. They know "encrypted at rest" doesn't say whether the keys are managed properly. They know the diagram shows the happy path, not the edge cases where controls break down.
A hypothetical to make it concrete: a diagram shows traffic encrypted between two services. The reviewer ticks the box. An engineer who has seen the deployment knows one service reaches the other through a debugging endpoint that skips the encrypted path. The diagram was accurate about the design and silent about the behavior.
The same gap shows up in code review. A scanner finds known vulnerability patterns. A trained engineer finds the ones that don't match a pattern: an authorization check that runs in the wrong order, input validation that handles the documented cases but not the undocumented ones, a library that's safe on its own and unsafe in combination with the rest of the system.
None of this means compliance professionals should become engineers. It means security teams benefit from having both capabilities, and the two groups need enough shared vocabulary to make their perspectives additive rather than parallel.
Isolated Controls vs. Attack Chains
The two frames also differ in how they treat context.
Compliance tends to evaluate controls one at a time. Is the credential stored securely? Is the connection encrypted? Is the certificate valid? Each is a binary question with a checkable answer.
Engineering tends to evaluate controls in the context of the full attack chain. What would an attacker need to do before reaching this control? What else have they compromised by then? Does this control change what they can do next?
That changes the cost-benefit math. A control that looks essential in isolation may be redundant given others already in place. A control that looks minor may be the one chokepoint an entire attack chain depends on. Neither is visible without understanding the system as a whole. Both questions are legitimate, and neither is sufficient alone.
What Better Looks Like
The goal isn't to make compliance professionals think like engineers or the reverse. It's to make the conversation between them productive. None of this needs an organizational transformation.
Start with the threat model. Before arguing about whether a control is present or a finding is valid, agree on what you're trying to prevent. "What does an attacker need to do to reach this?" is a question both sides can engage with, and the answer reframes everything around risk rather than compliance.
Translate before you respond. When a compliance professional is about to say "this doesn't meet the standard", the more useful version is "without this control, an attacker who has achieved X can now do Y." When an engineer is about to say "this isn't a real vulnerability", the more useful version is "this is theoretically valid, but the vulnerable path isn't reachable from external input because of Z." Both cost almost nothing.
Use the exception process. Put the engineer's reasoning in writing, with a compensating control, an owner and a review date. Disagreement then ends in a decision instead of a stalemate.
Treat the diagram as a starting point. Diagrams show intended design. Assessment has to account for the gap between what was designed and what was built, and between what was built and how it behaves under attack.
Measure trends, and still keep the snapshots. One missed metric is noise; three in a row in the same area is a signal. Audits and SLAs will still demand point-in-time evidence, so report both: the snapshot for the auditor, the pattern for leadership.
Hold joint reviews on contested findings. The most effective thing a security leader can do is put compliance and engineering in the same room on the same finding and require a shared conclusion about whether it's real risk. This doesn't scale to every finding, so reserve it for the high-impact or disputed ones. The translation happens in the room, and both sides leave with a fuller picture.
Learn enough of the other frame to ask its questions. Compliance professionals don't need to read code, but they should be able to ask "is this code path reachable from an external input?" Engineers don't need to know every regulation, but they should understand what a control is trying to prevent and what happens organizationally if it fails.
The Shared Goal
Compliance and engineering security aren't opposed. They address the same problem from different angles, with different tools, for different audiences.
Compliance creates the accountability structures organizations need to function at scale and satisfy outside requirements. Engineering creates the technical understanding that makes those structures meaningful rather than performative.
The conversation breaks down when either side assumes the other's frame is wrong rather than incomplete. A compliance professional who waves off an engineering concern as "not a policy issue", and an engineer who waves off a requirement as "checkbox theater", are making the same mistake: treating their frame as sufficient.
The most effective teams have both capabilities and a shared vocabulary for translating between them. That translation is where the real security work happens, not in the dashboard and not in the code, but in the conversation between the people who understand both.
Top comments (0)