Frequently asked questions

Beacon Standards is an open framework for categorising and prioritising cybersecurity findings. It sorts every finding into one of three tiers — Critical, Regulatory, or Best Practices — using a fixed decision procedure, and assigns each tier a remediation SLA. The framework is scanner-agnostic: it categorises findings from any tool, and provides a catalog of canonically-identified finding classes that scanner output maps into.

Five-level severity scales fail in practice because the middle levels carry no decision. A finding rated Medium tells an engineer nothing about when to fix it or whether it may be deferred. Beacon's three tiers each correspond to a distinct organisational response: Critical pre-empts planned work, Regulatory is scheduled against the audit calendar, and Best Practices is drawn from a standing capacity allocation. Three tiers is the smallest number that captures genuinely different responses, and every tier maps to a different budget and a different owner.

Apply four questions in strict order and stop at the first that returns yes. First: is it reachable by an untrusted party right now? Second: does exploitation grant access, privilege, or data without a chain of unlikely preconditions? If both are yes, it is Tier 1. Third: would a named auditor, regulator, or contractual counterparty record it as a deficiency? If yes, it is Tier 2. Fourth: does fixing it reduce future Tier 1 and Tier 2 findings? If yes, it is Tier 3. Order matters — evaluating compliance before reachability is the single most common cause of misclassification.

Identifiers take the form BCN-T{tier}-{DOMAIN}-{number} — for example BCN-T1-NET-001 is the first Network-domain finding in Tier 1. Domain codes are NET (Network), IAM (Identity and Access Management), DAT (Data Protection), and PRC (Processing Protection). Identifiers are permanent and are never reused: a finding may be reworded, re-mapped, or superseded, but its identifier continues to refer to the same finding class so that citations in reports and tickets remain valid.

Yes, and this is a designed behaviour rather than an exception. Tier assignment depends on context — principally reachability and the data at stake — so the same technical condition can be Tier 1 in one environment and Tier 3 in another. An unencrypted database reachable from the internet is Tier 1; the same database on an isolated segment with no regulated data is Tier 3. Tier also changes when context changes: removing internet exposure legitimately reduces a Tier 1 finding, which is why withdrawing reachability is often the fastest available remediation.

CVSS scores the intrinsic severity of a vulnerability; Beacon assigns an organisational response. They answer different questions and are complementary rather than competing. CVSS has no concept of whether the vulnerability is reachable in your environment, whether anyone is exploiting it, or whether it carries a compliance obligation — and published research has repeatedly found that remediating by CVSS score alone performs little better than remediating at random. Beacon uses CVSS as one input among several, alongside reachability, observed exploitation, and regulatory consequence.

EPSS and KEV are exploitation-likelihood signals, and Beacon consumes both as Tier 1 inputs. KEV membership means exploitation is confirmed, which combined with reachability places a finding in Tier 1 regardless of CVSS score. EPSS provides a modelled probability useful for prioritising within the queue and for triaging CVEs not yet in KEV. Neither is a categorisation framework: they tell you how likely exploitation is, not what your organisation should do, who owns the work, or by when. Beacon supplies that layer.

SSVC is a decision-tree methodology for vulnerability triage, developed at Carnegie Mellon's SEI, and it is rigorous and well-founded. Beacon differs in two respects. First, scope: SSVC addresses software vulnerabilities, while Beacon also categorises misconfigurations, identity weaknesses, and process gaps, which together account for the majority of findings in a modern cloud estate and carry no CVE. Second, output: SSVC produces a decision such as act or defer, whereas Beacon produces a tier with an attached SLA, owner, and escalation path. Organisations already using SSVC can treat its output as an input to Beacon's first two questions.

Any of them. Beacon deliberately defines finding classes rather than tool integrations, so scanner output maps into the catalog rather than the catalog being derived from any one tool. The site documents mappings for commonly-used tools including Nmap, Nessus, Qualys, Burp Suite, OWASP ZAP, Nuclei, Trivy, PROWLER, Cloudsploit, and ScoutSuite, but the mapping exercise is the same for any tool that produces findings.

A first pass over an existing backlog typically takes a few days for one person: classify the open findings, then confirm the Tier 1 set with the teams who own the systems. The harder and more valuable work is operational — agreeing SLAs with engineering leadership, wiring tiers into the existing ticketing system, and establishing the exception process. Most organisations reach a working state within a quarter. Adopting the tiering without agreeing the SLAs produces a relabelled backlog and no change in behaviour.

Record the exception rather than quietly extending the deadline. A Tier 1 finding that cannot be remediated within 72 hours requires a documented compensating control, a named accountable owner, and a review date — and the escalation to executive level is the mechanism that either produces the resources or produces an explicit, accountable decision to accept the risk. Silently missing SLAs is the failure mode that destroys the framework's value: once the Tier 1 queue contains items that have been open for months, the tier stops meaning anything.

No. Beacon is a prioritisation framework and does not replace any regulatory or certification standard. It maps to them: each catalog entry lists the specific controls it relates to across PCI DSS v4.0, HIPAA, GDPR, SOC 2, ISO/IEC 27001:2022, NIST CSF 2.0, and CIS Benchmarks. The Regulatory tier exists precisely so that compliance-driven work is scheduled against the audit calendar rather than competing with threat-driven work for the same urgency.

Beacon Standards is published by Penti.ai, building on work originated at Securily, and is released under GPL-3.0. The framework is developed openly: the catalog, tier definitions, and mappings are public, and the machine-readable catalog is available for use in other tools. Corrections and additions are accepted through the public repository.

Yes. Beacon is released under GPL-3.0 and the finding catalog is published as machine-readable JSON specifically so it can be embedded in scanners, ticketing systems, and reporting tools. Cite findings by their canonical identifier so that readers can resolve them — identifiers are permanent, which is what makes them safe to reference in a report that will be read years later.