Skip to content
Implementation

Adopting Beacon

Classifying a backlog takes a few days. Changing what an organisation does about it takes a quarter. This is the part of adoption that actually determines whether anything improves, so it is written in the order the work happens.

The framework is free and the classification is fast. The scarce resource is the agreement from engineering leadership that Tier 1 pre-empts planned work — everything else is logistics.

Week 1

Classify what you already have

Goal — A tiered backlog and an honest count of Tier 1 items.

  • Export every open finding from every source — scanners, cloud posture tools, the last penetration test, and the architecture review notes nobody actioned.
  • Apply the four-question decision procedure to each. Do not enrich, deduplicate, or clean up first; classification is fast and the cleanup is easier once findings are tiered.
  • Map each to a catalog identifier where one fits. Findings with no catalog match are expected — record them and classify them the same way.
  • Count the Tier 1 items. This number is the single most important output of the week, and it is usually smaller than the team expects and older than anyone is comfortable with.
Where this goes wrong

Resist the urge to fix things during classification. Mixing the two means neither finishes, and the Tier 1 count — which is what secures the resources — never gets produced.

Weeks 2–3

Agree the SLAs with the people who will meet them

Goal — Written agreement from engineering leadership on tier SLAs and escalation.

  • Present the Tier 1 list to engineering leadership with the classification rationale for each. The rationale is what converts an argument about severity into a conversation about scheduling.
  • Agree the SLA per tier. Beacon's defaults — 24–72 hours, 30 days, 90 days — are a starting point; an SLA your organisation will actually meet beats a stricter one it will not.
  • Agree the escalation path explicitly, including who receives the 48-hour Tier 1 escalation and what they are expected to do about it.
  • Agree where Tier 3 capacity comes from. A standing percentage of engineering time is the only mechanism that works; anything drawn from slack time will not happen.
Where this goes wrong

This is the phase organisations skip, and skipping it is why most prioritisation frameworks become a relabelled backlog. Tiering without agreed SLAs changes nothing.

Weeks 3–4

Wire tiers into the system engineers already use

Goal — Findings arriving as tickets in the existing tracker, tagged with tier and domain.

  • Route findings into the existing engineering tracker. A security-only tool that engineers do not open is a queue nobody works.
  • Encode tier as a field that drives due dates automatically, rather than as a label someone sets by hand.
  • Route by domain to the team that owns the relevant control, so the ticket arrives at someone who can act on it.
  • Set up the escalation as an automated notification on SLA breach, not as a manual report someone remembers to run.
Where this goes wrong

Automate the due date from the tier. Any process requiring a human to calculate a deadline will drift within a month.

Ongoing

Run the exception process honestly

Goal — Every unmet SLA is a recorded decision rather than a silent miss.

  • When a Tier 1 item cannot be remediated in time, escalate it. That is what the escalation path is for — it produces either the resources or an explicit, accountable decision to accept the risk.
  • Record every exception with a named owner, a compensating control, and an expiry date. Exceptions without expiry dates become permanent, which is a finding in its own right.
  • Review expiring exceptions on a schedule, and treat a second renewal as a signal that the underlying problem needs a different approach.
  • Report SLA attainment by tier. Measure time to remediate, not time to acknowledge — programmes that measure acknowledgement report numbers unrelated to actual exposure.
Where this goes wrong

A Tier 1 queue containing items open for months destroys the framework. Once the top tier stops meaning 'this week', it stops meaning anything, and no amount of process recovers it.

Reference

The default SLA policy

Copy this into your policy document and adjust. The defaults are chosen so that Tier 1 is shorter than typical attacker dwell time — an SLA longer than the attack window is not a control.

Tier 1 · CriticalStop active bleeding

Tier 1 covers conditions an attacker can act on now. The defining property is not severity score but reachability: the vulnerability is exposed to an untrusted network, exploitation is understood and tooled, and success grants meaningful access. These are the findings that show up in breach post-mortems.

Remediate within
24–72 hours
Escalation
CISO and executive sponsor notified at 48 hours
Owner
Security operations, with a named engineering owner per finding
Capacity
Unplanned work — Tier 1 pre-empts sprint commitments
Tier 2 · RegulatoryMaintain the licence to operate

Tier 2 covers conditions that threaten certification, contract, or regulatory standing. The consequence is not a breach but a finding in someone else's report: a qualified SOC 2 opinion, a failed PCI DSS assessment, a GDPR Article 32 exposure. These are deadline-driven rather than threat-driven, and the deadline belongs to the auditor.

Remediate within
30 days
Escalation
Security manager review at 14 days
Owner
Compliance, with engineering executing the remediation
Capacity
Planned work — scheduled against the audit calendar
Tier 3 · Best PracticesReduce the rate at which the first two tiers refill

Tier 3 covers structural improvements with compounding returns. Nothing here is urgent in isolation, which is exactly why it never gets done without a tier of its own. Tier 3 is the only tier where deferral is a legitimate, recorded outcome — an organisation that closes every Tier 3 item is probably under-investing elsewhere.

Remediate within
90 days
Escalation
Reviewed at quarterly planning; may be formally deferred
Owner
Platform and engineering teams
Capacity
Planned work — a standing percentage of engineering capacity
Measurement

Six metrics worth reporting

Chosen because each one changes a decision. Metrics that only demonstrate activity are why security reporting gets ignored.

Tier 1 SLA attainment

Percentage of Tier 1 findings remediated within 72 hours of identification.

The headline number. If this is below 80% the SLA is wrong or the resourcing is, and either way the framework is not yet operating.

Tier 1 queue age

Age of the oldest open Tier 1 finding.

A single item open for months does more damage to the framework's credibility than a dozen recent ones. This is the number to put in front of an executive.

Classification stability

Proportion of findings whose tier is changed after initial assignment.

High churn means the decision procedure is being applied inconsistently. Persistent disagreement on the same finding class usually means the catalog entry needs clarifying.

Tier 3 completion rate

Proportion of Tier 3 findings closed or formally deferred within 90 days.

Tier 3 is where preventive work lives. A programme that never closes Tier 3 items will keep refilling Tiers 1 and 2 indefinitely.

Open exceptions with expired review dates

Count of risk acceptances past their review date without reassessment.

The clearest early indicator that governance has become paperwork. This number should be zero and rarely is.

Findings per source, by tier

Distribution of tiers across scanners, penetration tests, and reviews.

Shows which sources produce actionable findings. A tool generating thousands of results that all classify as Tier 3 is worth reconfiguring or removing.

Integration

Wiring the catalog into your tooling

All 36 finding classes are published as JSON so they can be consumed directly rather than transcribed.

curl -s https://beaconstandards.com/beacon-catalog.json | jq '.findings[] | select(.tier == 1) | {id, name, sla}'

# Every entry carries:
#   id            BCN-T1-NET-001 — permanent, never reused
#   tier          1 | 2 | 3
#   domain        network | iam | data | processing
#   sla           remediation deadline for this finding
#   detection[]   how to determine whether you have it
#   remediation[] ordered steps
#   verification  the test that proves it is fixed
#   mitre[]       ATT&CK techniques
#   compliance[]  framework and control references
Download catalog JSONRepository

Start with the classification

Everything above depends on being able to tier a finding consistently. That is one page, four questions, and about ten minutes.

The decision procedure