Skip to content
← All articles

Operating GRC at AI Speed · Episode 7

May 25, 2026

Policy tiering breaks when controls ship weekly

By Ben Draffin · Director of Security at Decagon

Every GRC framework describes the same pyramid: policy sets intent, standards narrow it, procedures tell people what to do, and controls prove it happened. The model is sound. The cadence it assumes is not.

Most tiering guidance was written for organizations where policy committees meet quarterly and engineering ships on a recognizable release train. At an AI-native company selling into enterprise, the train is weekly—or faster—and the controls that matter to buyers often land in a merged PR before anyone schedules a policy review. The hierarchy still matters for auditors and customers. The refresh cycle does not.

When tiering is treated as a slow cascade from the top, you get one of two failures: polished policy documents that describe last quarter’s product, or a strong technical program that cannot explain itself consistently in questionnaires and audit interviews. Neither closes enterprise deals.

What the classic pyramid assumes

Traditional tiering works when each layer has a stable owner and a predictable update rhythm.

Layer Typical owner Classic refresh cadence What it is supposed to do
Policy Legal / GRC leadership Annual or biennial State organizational intent and non‑negotiables
Standard GRC + domain leads Semi-annual Translate policy into measurable requirements
Procedure Operations / IT / Engineering As needed Document repeatable steps
Control Engineering + GRC Continuous Demonstrate the requirement is operating

The implicit contract: policy leads, everything else follows. That contract holds when implementation velocity is slower than governance velocity. It breaks when the opposite is true—which is the default at AI-native scale.

How AI-native shipping inverts the stack

Three patterns show up repeatedly in production GRC programs I work with:

  1. Controls emerge bottom-up. Retention configuration, model routing rules, authorization checks, and logging land in infrastructure and application code before policy language exists. That is not shadow IT. It is how fast teams close security gaps customers already named in redlines.

  2. External claims lag internal reality. Questionnaires, trust pages, and SOC descriptions get written once and reused until a deal stalls. Meanwhile, engineering has shipped three iterations of the control the questionnaire still describes in the subjunctive.

  3. “Procedure” lives in runbooks and PR templates. Engineers do not open a PDF to deploy. They follow CI gates, code review norms, and incident runbooks. Calling that a “procedure document” misses where work actually happens—and where evidence actually lives.

The result is an inverted stack in practice: implementation → implicit standard → policy catch-up. That inversion is not a maturity failure. It is a speed artifact. The job is to make the inversion visible and governable, not to pretend the pyramid refreshed itself.

Where rigid tiering fails enterprise buyers

Enterprise security reviews do not ask whether your tiering model is textbook-correct. They ask whether what you claim, what you show, and what runs in production describe the same company.

Failure mode What buyers see Underlying tiering mistake
Policy-rich, evidence-thin Confident narrative; weak demo path Policy refreshed; standards and controls did not
Implementation-rich, story-thin Strong engineering; inconsistent questionnaire answers Controls exist; no reconciled standard layer
Procedure theater Thick binders; auditors cite “not operating effectively” Procedures written for auditors, not operators
Tier confusion “Is this a policy or a standard?” escalations on every deal Layers used as prestige labels, not as different refresh speeds

The last row is more common than teams admit. When every document is called a “policy” because policy sounds authoritative, you lose the whole point of tiering: different layers can move at different speeds.

A tiering model that matches AI speed

You do not need to abandon policy, standard, and procedure. You need to resize the layers and decouple their cadences.

1. Keep the policy layer short and durable

Policy should state what the organization will not compromise on—data handling principles, access expectations, incident reporting obligations—not enumerate every technical control variant. Shorter policy is easier to keep true and easier to defend in auditor interviews.

If your policy document reads like a SOC control matrix, it is doing standards’ job at policy’s refresh rate. That is how you get annual documents that are obsolete in March.

2. Treat standards as the reconciliation layer

Standards are where policy intent meets production reality. This is the layer that should update when inventories change, when a new enterprise clause lands, or when a pen test finding closes.

Pair standards refresh with the reconciliation workflow from Merge coding-agent inventories with policy: aligned claims, policy-only gaps, implementation-only wins. Standards are the written output of that exercise—not a separate annual project.

3. Let procedures live where work happens

Procedures belong in runbooks, deployment checklists, on-call playbooks, and PR templates—not only in standalone Word files. GRC’s job is to index and review those artifacts on a cadence, not to duplicate them into a library no engineer opens.

Auditors care that procedures exist and operate effectively. They do not care whether the procedure is a Confluence page or a checked box in CI—provided you can show both the document and the evidence trail.

4. Run the two-way loop on purpose

Tiering is not a one-way waterfall. Sometimes policy leads—new certification scope, regulatory change, a must-have redline. Sometimes controls lead—product ships first. The mature pattern is the loop described in Policies should follow controls, not the other way around: detect which direction is dominant, reconcile on a schedule, and update the right layer.

Cadence table: what to refresh when

Use different clocks for different layers. The mistake is syncing everything to the slowest clock.

Layer Suggested cadence (AI-native) Trigger events
Policy Annually, plus material legal/regulatory change New market entry, major incident, board mandate
Standard Monthly or per release train Inventory drift, closed pen test, new enterprise clause
Procedure Continuous; formal review quarterly Runbook change, new CI gate, org restructure
Control evidence Continuous Every deploy, scanner pass, agent inventory run

Monthly standard refresh sounds aggressive until you compare it to weekly shipping. It is conservative relative to product velocity—and still faster than the annual policy cycle most frameworks assume.

A 90-minute tiering audit

You can learn whether tiering is helping or hurting without a reorg.

  1. Pick five controls your largest customers asked about last quarter.
  2. For each, locate four artifacts: policy statement, standard requirement, procedure (or runbook/CI equivalent), and production evidence.
  3. Note the last updated date on each artifact and whether implementation or documentation came first.
  4. Mark gaps: policy-only, implementation-only, or mis-tiered (standard language hiding in policy, procedure duplicated but not operated).
  5. Agree on one action per control: narrow policy, write/update standard, index procedure, or collect evidence.

If most gaps are policy-only, your narrative is ahead of production—common in top-down-dominant orgs. If most are implementation-only, your program is stronger than your external story—common in bottom-up-dominant orgs. Either way, tiering should make the gap visible, not hide it behind document count.

What not to do

Do not slow shipping to refresh policy. If the control is right and the customer need is real, ship—then reconcile the standard layer on the next cycle. Deals and incidents do not wait for committee schedules.

Do not collapse all layers into one document to “simplify.” You lose the ability to refresh standards without reopening board-level policy language.

Do not treat tiering as org chart prestige. Product security, corporate security, and GRC can all own pieces—but each layer needs a named refresh owner, or it will drift by default.

How this fits the series

Tiering is the scaffolding around the two-way loop. Redlines tell you where external language still exceeds production. Vendor contracts import market expectations into your standard layer. Coding-agent inventories supply the evidence standards must track. Audit prep stress-tests whether each tier survives human follow-up questions. Cert sequencing from pipeline decides which attestation forces the next standard refresh.

Operating GRC at AI speed means right-sizing the pyramid: durable policy at the top, fast standards in the middle, procedures where engineers already work, and controls measured continuously—not a single annual cascade pretending the product stood still.


Previous: Choose compliance certifications from your sales pipeline · Policies and controls two-way loop

Series

Newsletter

Email when I publish.

You'll get a confirmation email first.

Share on LinkedIn · Pushback? LinkedIn is fine.