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 this happens is the first step toward making the conversation more 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. And the gap between them is where a lot of organizational security risk lives unexamined.
Compliance security exists for good reasons. Regulatory frameworks, audit requirements, and industry standards create accountability structures that organizations need. They provide common baselines, defensible documentation, and a shared vocabulary for talking about risk at an organizational level. Without them, security would be entirely ad hoc, inconsistently applied, and impossible to verify externally.
But compliance frameworks are necessarily backward-looking. They codify what has gone wrong before. They describe controls that were adequate for the threat landscape when they were written. They measure whether a control is present, not whether it is effective against the specific 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 logical 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. But organizations tend to hire heavily toward one or the other, and the resulting teams often struggle to have a productive conversation.
Compliance wants a standard in place. Not all applications are standard, but can still be secure in their own way.
The Metric Is Not the Goal
One of the clearest symptoms of the disconnect is how each group thinks about metrics.
Compliance security tends to measure presence and frequency. Is the control documented? Is the scan running? Did the patch get applied within the SLA window? These are measurable, auditable, and reportable. They produce the dashboards that leadership sees and the evidence packages that auditors review.
Engineering security tends to be skeptical of metrics for the same reasons compliance security values them. A metric tells you whether something happened, not whether it mattered. An application that missed a patching metric for one month could be in a planned maintenance window, working through a dependency conflict, or genuinely exposed — the metric doesn't tell you which. Chasing the metric without understanding the context can produce a lot of activity that generates no meaningful improvement in security posture.
This isn't to say metrics are useless. They're valuable for identifying trends, allocating resources, and communicating status to stakeholders who need a summary view. But a single data point is noise. A pattern over time is signal. The mistake is treating noise as signal because the reporting cadence demands an answer.
The practical consequence is that compliance-focused teams can spend significant energy on findings that don't change real exposure, while genuinely risky conditions go unexamined because they don't map cleanly to a standard.
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.
This is compounded by the nature of many scanner-generated findings. Automated tools flag vulnerabilities based on version numbers, known patterns, and configuration checks — without knowing whether the vulnerable code path is reachable from an external input, whether the application actually uses the affected function, or whether compensating controls make exploitation impractical regardless of the CVE score. Many findings are theoretically valid and practically irrelevant. Closing them satisfies the metric. It doesn't change what an attacker can do. Meanwhile the handwritten authentication logic three files over — the kind of issue no scanner would ever surface — goes unexamined because it doesn't show up in the report.
False positives make this worse in a way that's easy to underestimate. When a significant portion of findings turn out to be invalid, the completion rate metric becomes meaningless — you're measuring how fast you can close things that shouldn't have been opened. Engineers learn quickly that findings can't be trusted at face value and start treating everything as noise. Remediation slows down not because teams are negligent but because the signal-to-noise ratio is poor enough that prioritization becomes guesswork. The compliance team sees low completion rates and escalates. The engineering team sees an unreliable finding queue and deprioritizes. Both sides are responding rationally to their own view of the situation, and the conversation goes nowhere. The number gets chased. The risk doesn't get managed.
The Code Problem
There is a specific version of this disconnect that deserves its own discussion: what happens when security professionals who can't read code try to assess systems built by engineers who don't think about security.
Consider the common practice of reviewing architecture diagrams for security findings. A compliance-trained security professional can identify whether required components are present — firewalls, encryption at rest, access controls. What they often can't identify is what's missing from the diagram that would change the assessment entirely. The hidden proxy that all cross-region traffic is supposed to traverse. The authentication check that should be on every endpoint but isn't. The configuration that looked correct in the diagram and is subtly wrong in implementation.
An engineer reading the same diagram fills in those gaps automatically, because they know how the system actually behaves. They know that AWS regions don't communicate natively without explicit configuration. They know that "encrypted at rest" in the diagram doesn't tell you whether the encryption keys are managed correctly. They know that the diagram shows the happy path, not the edge cases where security controls break down.
The same gap appears in code review. A scanner can identify known vulnerability patterns. A trained engineer can identify the ones that don't match known patterns — the authorization check that's present but evaluated in the wrong order, the input validation that handles the documented cases but not the undocumented ones, the third-party library that's used correctly in isolation but incorrectly in combination with the rest of the system.
This isn't an argument that compliance professionals should become engineers. It's an argument that security teams benefit from having both capabilities represented, and that the two groups need to develop enough shared vocabulary to make their different perspectives additive rather than parallel.
The Architecture of Risk
Another place the two frames diverge is in how they think about risk context.
Compliance security tends to evaluate controls in isolation. Is the credential stored securely? Is the connection encrypted? Is the certificate valid? Each of these is a binary question with a checkable answer.
Engineering security tends to evaluate controls in the context of the full attack chain. What would an attacker need to do before they could reach this control? What else have they compromised if they've gotten this far? Does the presence or absence of this control change what they can do next?
This difference matters significantly when evaluating whether a given control is worth its cost and complexity. A control that looks necessary in isolation may be redundant given other controls already in place. A control that looks minor in isolation may be the critical chokepoint that an entire attack chain depends on. Neither of these becomes visible without understanding the system as a whole.
The practical consequence is that compliance-driven security conversations often focus on whether controls exist, while engineering-driven security conversations focus on whether the combination of controls changes the outcome for a motivated attacker. Both questions are legitimate. Neither is sufficient alone.
What Better Looks Like
The goal isn't to make compliance professionals think like engineers or engineers think like compliance professionals. The goal is to make the conversation between them more productive. The framing problem doesn't require an organizational transformation to start addressing — there are things each group can do immediately.
Start with the threat model. Before discussing whether a control is present or a finding is valid, establish shared context around what you're actually 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 every subsequent discussion 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 finding is theoretically valid but the vulnerable code path isn't reachable from an external input because of Z." Both translations cost almost nothing and make the conversation dramatically more productive.
Treat the diagram as a starting point, not the answer. Architecture diagrams show intended design. Security assessment needs to account for the gap between what was designed and what was built, and the gap between what was built and how it behaves under adversarial conditions.
Measure trends, not snapshots. A single missed metric is noise. Three consecutive missed metrics in the same area is a signal worth investigating. Security reporting that surfaces patterns rather than point-in-time states gives leadership more actionable information and gives security teams more defensible prioritization decisions.
Create deliberate joint reviews. The most effective thing a security leader can do is put compliance and engineering professionals in the same room on the same finding and require them to reach a shared conclusion about whether it represents real risk. Not to present to each other — to work through it together. The translation happens in the room, and both sides leave with a more complete picture than either had walking in.
Learn enough of the other frame to ask better 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 regulatory requirement, but they should understand what the control is trying to prevent and what happens organizationally if it fails. Neither group needs to become the other. Both groups benefit from understanding enough of the other's frame to ask the question that the other side would ask.
The Shared Goal
Compliance security and engineering security are not in opposition. They're addressing the same underlying problem from different angles, with different tools, optimized for different audiences.
Compliance creates the accountability structures that organizations need to function at scale and satisfy external requirements. Engineering creates the technical understanding that makes those structures meaningful rather than performative.
The conversation breaks down when one side assumes the other's frame is wrong rather than incomplete. A compliance professional who dismisses engineering concerns as "not a policy issue" and an engineer who dismisses compliance requirements as "checkbox theater" are both making the same mistake — treating their frame as sufficient rather than as one perspective on a complex problem.
The most effective security teams have both capabilities and have done the work to develop a shared vocabulary that lets them translate between frames. That translation is where the real security work happens — not in the dashboard, not in the code, but in the conversation between the people who understand both.
Top comments (0)