The Security Posture Question Most Organizations Ask Too Late

• Mon, Aug 14, 2023
• 7-minute read

“What’s our actual security posture?” is a question most organizations ask too late. Not the one in the deck. The one that explains how something just happened, or what a regulator is about to find, or what an acquirer’s diligence team is asking for in writing.

Four triggers force the question. Three produce the same work under unfavorable conditions: an incident, an acquisition, a regulatory deadline. The fourth produces the same work in calm conditions, with budget and time. The trick is engineering trigger four before any of the others fires.

Figure 1. Three of the four triggers produce the same posture work under pressure. The fourth produces the same work in calm conditions. The cost difference between them is large and front-loaded toward the first three.

The incident

The most common trigger is also the most expensive. The question gets asked while you’re containing damage, which means the answers come from whoever’s in the war room, often without time to verify.

A SaaS I advised through a Sunday-afternoon breach, one that had been operating at scale for several years without a major incident, discovered their gaps in three places at once. The forgotten staging environment had a firewall rule added “temporarily” two years prior. There was no detection coverage on egress traffic from staging, because nobody had thought of staging as a path to production data. The audit trail in the affected service had been silently truncated by a logging-cost optimization six months earlier. None of this was in the security narrative. All of it was in the architecture.

The cost is the incident itself, plus the credibility of the security story you’ve been telling internally and to customers. Both costs compound. The customer who asks “what changed?” expects a different answer than the true one, and that gap becomes months of communication work for the security team.

The acquisition

The acquirer’s diligence team asks for documentation you don’t have, ratios you’ve never measured, and proof that controls operated correctly over the last 12 months. The control exists in the policy. The evidence that it fired correctly is the part you didn’t keep.

A mid-size SaaS I advised through late-stage acquisition diligence, one that had built a solid product but treated security operations as a background task, got asked to demonstrate that their quarterly access reviews had fired in each of the last four quarters. The reviews had been performed half the time and skipped the rest during a stretch when the security lead was hiring a backfill. Producing those artifacts retroactively wasn’t possible. The fix was an emergency remediation negotiated as a closing condition, with the acquirer’s security team setting the agenda for the first two quarters after close. This is what access debt looks like when the bill arrives at once, with a calendar deadline next to it.

Regulatory pressure with teeth

A new framework comes into force, or a regulator opens an inquiry, and your compliance posture suddenly has a gap to close on a calendar nobody at your company set.

A biomedical startup I worked with had been operating under HIPAA-aligned assumptions that covered their research data handling well enough. A new state privacy law added requirements that didn’t map cleanly onto those controls. The team spent several months building toward a deadline with statutory penalties for missing it, discovering that several data-handling controls had been operating on optimistic assumptions about what the law required. This is the pattern where compliance starts becoming a substitute for security thinking: remediation cycles favor the controls auditors can verify over the ones that reduce risk.

The senior leader who hasn’t yet inherited the consequences

A new CISO, CTO, or board member asks the question before they own the answer. They have the standing to ask early, and not yet the political cost of finding the answer uncomfortable. That window doesn’t last long.

A new head of engineering at a mid-size edtech I worked with asked for a security posture review in their first couple of months. The review surfaced three gaps. All three got funded and remediated within the year. None of them later contributed to an incident, an acquisition surprise, or a regulatory finding. The new lead got credit for finding the gaps. The previous team didn’t get blame for missing them, because the new leader had political capital they were willing to spend on framing it as new context. The cost of the work was absorbed in the normal budget cycle. That’s the trigger you want.

Engineering the fourth trigger yourself

The way to avoid the first three is to engineer the fourth. The pattern that holds up has five elements: an annual posture review embedded in architectural review; a threat model that gets updated rather than left as a slide that’s been the same for three years; quarterly tabletop exercises with findings that feed the gaps list; treating “we don’t know” as an acceptable answer that drives investigation rather than a failure to admit; and senior backing for a cadence that prioritizes honesty over comfort.

That last element is the one that fails most often. The posture review that starts honest tends to drift back toward a narrative exercise within two cycles once it stops being new. The political capital required to keep it honest has to be committed in advance, not drawn on during the review itself.

Here is the assessment template that anchored that review:

# security-posture-assessment.yaml
# Annual review template. One entry per domain.
# Date and owner on every domain — if older than 12 months, escalate.

review:
  date: "2023-08-14"
  owner: "CISO"
  next_review: "2024-08-14"
  scope: "Production cloud environment and supporting systems"

domains:
  - name: Identity and access
    last_reviewed: "2023-07-01"
    reviewer: "Security Engineering Lead"
    controls_verified:
      - label: "Quarterly access reviews completed"
        status: "partial"   # completed 2 of 4 quarters
        evidence: "access-review-artifacts/2023-q1, 2023-q2"
        gap: "Q3 review not yet completed; Q4 not started"
        remediation_owner: "IAM team"
        remediation_due: "2023-09-30"
      - label: "MFA enforced for all admin roles"
        status: "pass"
        evidence: "idp-config-audit-2023-07.pdf"
    posture_rating: "yellow"   # green / yellow / red

  - name: Detection and response
    last_reviewed: "2023-06-15"
    reviewer: "SecOps Lead"
    controls_verified:
      - label: "Egress monitoring on all environments"
        status: "fail"
        evidence: null
        gap: "Staging egress not monitored"
        remediation_owner: "Platform Security"
        remediation_due: "2023-10-01"
      - label: "Alert queue monitored 24/7"
        status: "pass"
        evidence: "oncall-rotation-2023.yaml"
    posture_rating: "red"

  - name: Data protection
    last_reviewed: "2023-07-20"
    reviewer: "Data Platform Lead"
    controls_verified:
      - label: "Encryption at rest for all PII stores"
        status: "pass"
        evidence: "kms-audit-2023-07.pdf"
      - label: "Audit logs retained 12 months"
        status: "partial"
        evidence: "log-retention-config.yaml"
        gap: >
          One service silently truncated logs after cost-reduction
          change in January. Retention now 45 days for that service.
        remediation_owner: "Security Engineering"
        remediation_due: "2023-09-15"
    posture_rating: "yellow"

# Aggregate summary
summary:
  green_domains: 0
  yellow_domains: 2
  red_domains: 1
  open_gaps: 3
  gaps_due_this_quarter: 3
  executive_narrative: >
    Three open gaps, two of which were surfaced by this review for
    the first time. All three are remediable within the quarter.
    No indicators of compromise identified during review period.

Figure 2. Self-initiated posture work and incident-driven posture work converge on the same remediation tasks. The difference is the conditions under which you do the work, and who sets the agenda.

That SaaS eventually rebuilt their posture review process. The first version, run six months after the breach, was honest in a way the previous two years of reporting hadn’t been. The list of gaps was longer than anyone expected. So was the list of gaps closed within twelve months. The pattern that worked wasn’t new tools. It was the standing to ask the question without an incident giving permission.

What I don’t have a clean answer for is the harder version: when the political cost of honest self-assessment is higher than the political cost of waiting, how do you change that calculus before the incident lands?

Related Posts

• Infrastructure security architecture patterns
• Zero trust network architecture
• When compliance becomes a substitute for security thinking
• IAM sprawl is access debt
• The AI build vs buy decision