Your services all use mTLS but no compliance control covers it — why does that matter?
answer
- the report is the map
- not on the map, not funded
- no check means no red state
- assertion is not audit evidence
- map it to the objective it serves
basics
~20 sA defence nobody checks is invisible to the report leadership funds from. It gets no owner, no budget and no alarm when it regresses, it earns no audit credit, and a redundant product gets bought to solve it again.
solid answer
~50 sCompliance reporting is the map most organisations manage security by, and anything not on the map does not exist for budgeting, audit or leadership assurance. Service-to-service mTLS that every team just does is real risk reduction with no control, no owner and no check, so three things follow. It silently regresses: one team ships a service with verification disabled and nothing turns red. It earns nothing at audit, so you do the work and still answer 'no evidence' to the transmission-protection question. And it is invisible when the budget round asks what is already covered, so a redundant product gets bought. The fix is not more paperwork — it is a check on the property you already rely on, mapped to the framework objective it genuinely serves, so the defence shows up in the same report as everything else.
go deeper
Be ready to say why work nobody records is work nobody can defend at budget time or at audit, and that an assertion is not evidence.
Explain the mechanics: no check means no failure state, so the property can regress for years unnoticed, and the audit answer is a finding despite the work being done.
Show how you would find these defences from incident and near-miss reviews, then wire the cheapest detective check to the framework objective it already satisfies.
Own the portfolio view: a coverage map built only from framework controls will always misprice both your gaps and your strengths, and procurement decisions are made from that map.
## The inverse of a checkbox control Most of this topic is about controls that pass while the risk stays open. The mirror image is at least as common and gets discussed far less: **a real defence with no control behind it**. Service-to-service mTLS. Tiered egress that means a compromised batch worker cannot reach the internet. A review culture where nobody merges their own schema change. These reduce risk more than several green checkboxes combined, and they appear in exactly zero framework reports. ## Why invisibility costs you **It has no owner and no budget line.** Funding follows the report. A defence that is 'just how we do things' has no line item, so when the team that maintains it is reorganised, the work is not visibly dropped — it just stops. **It regresses silently.** This is the sharpest cost. A control has a check, and a check has a failure mode: when the property stops holding, something turns red. An unchecked defence has no failure mode at all. A new service ships with peer verification disabled to get past a certificate problem on a Friday, the intent is to fix it Monday, and nothing anywhere notices — for two years. Every checked control in the estate has a tripwire; this one does not. **It earns no audit credit.** Frameworks state objectives — protect data in transit, restrict network access to what is required — and ask for evidence. If your evidence for transmission protection is 'our engineers use mTLS everywhere', you have an assertion, not evidence. The auditor's question is answered with a finding, and the organisation is told to implement something it already implemented, usually in a shape worse than what it had. **It gets bought twice.** In a budget round, whatever is not on the coverage map looks like an uncovered risk. That is how an organisation with a mature egress tier ends up procuring an egress product, and how an existing mesh identity story loses to a slide. **It distorts the picture in the other direction too.** Leadership reading the report sees the checkbox controls as the security posture. When an incident is contained by the unlisted defence, the post-incident story credits whatever happened to be green, and the wrong thing gets reinforced. ## Finding them You cannot find these by reading the framework, because the framework is the thing they are missing from. Two sources work: - **Post-incident and near-miss reviews.** For the last handful of incidents, ask what actually stopped it from being worse. The answers are frequently unlisted defences, and that sentence is the start of a control. - **Architecture review and the engineers themselves.** Ask what they would be frightened of if a given property stopped holding. 'If someone turned off peer verification we would never know' is a defence with no control, stated out loud. ## Turning a defence into a control Write the check first, then the wording. For mTLS: query the mesh or platform configuration for services where peer verification is not required, and for workloads accepting plaintext on the service port. Give it an owner and put its result in the same report as everything else. Then map it to the framework objective it genuinely satisfies — transmission confidentiality and integrity, and often network access restriction as well — rather than inventing a new category, because the mapping is what converts your existing work into audit evidence. Even a **detective** check with a weekly cadence is worth far more than nothing: it gives the defence a red state, which is the whole point. A **preventive** gate at admission or deploy is better, but do not let the perfect version delay giving the property a tripwire. ## The honest caveat Not every defence needs a control. If the property is **structurally enforced** — non-mTLS traffic simply cannot establish a connection because there is no path that issues an identity for it — then the architecture is its own evidence, and a check is documentation rather than assurance. The harm arises when the defence is **convention**: something true today because everyone remembers to do it. Convention is exactly what a check exists to catch. Culture defences are the genuinely hard case. You cannot check 'the team reviews carefully'. You can measure proxies — proportion of changes with a reviewer outside the author's team, time-to-review distributions, self-merge counts — but a proxy metric becomes a target the moment it is reported, and it degrades. Name that limitation rather than pretending the proxy is the thing.
- Is a detective check on mTLS worth writing if you cannot enforce it at deploy time?Yes. The main value of a control here is not the block, it is the existence of a red state — something that changes when the property stops holding. A weekly query listing services that accept plaintext gives the defence an owner, a trend and an alarm. Enforcement at admission is strictly better and should follow, but shipping the detective version first is usually weeks rather than quarters.
- How do you handle a defence that genuinely cannot be checked, like review culture?Measure proxies and be explicit that they are proxies: reviewer independence, self-merge rate, the distribution of review latency rather than the average. Then say out loud that the proxy becomes a target once it is reported, so it is a trend to watch rather than a threshold to gate on. Claiming the proxy proves the culture is how a good defence turns into a bad metric.
A load-bearing wall that appears on no floor plan. Everything stands up fine until the day a renovation crew reads the plan.
saying these in an interview costs you the question
- Says an undocumented defence still counts because it works
- Treats the framework as a complete list of an organisation's defences
- Wants a policy document rather than a check with a red state
- Ignores that unchecked properties regress silently
- Claims a proxy metric fully captures a culture defence