Security work runs on decisions about which alerts to close, which domains to trust and which risks to accept. Your team makes them every day, and over the years they add up to the shape of your defenses. Each one made sense to someone at the time.
The context of record is what a security team knows and what it has decided, kept together with who made each decision, why and until when. It applies to a formal risk acceptance and a one-line allowlist entry alike, whether you run security in-house or for your clients as an MSSP.
FedRAMP’s 2026 rules replaced the System Security Plan with a Security Decision Record that cloud providers keep up to date for the life of their service. In the EU, NIS2 and DORA ask management bodies to approve how cyber risk is managed and hold them accountable for it. So “who decided this, and why?” is a question for the board as well as the SOC.
We’ll finish with the question a context of record lets your team ask.
What Is a Context of Record?
A context of record keeps each security decision next to the threat and environment context it was based on. A reason written in a ticket explains a decision once. A reason kept next to that context lets you see when it has stopped being true.
What Goes Into a Context of Record
Every decision in a context of record answers the same five questions.
- What: the decision itself, such as closing an alert as a false positive or trusting a domain.
- Who: the person accountable for it.
- Why: the reasoning, in a sentence or two.
- How: the method or evidence behind it, such as a sandbox report or an external scan.
- Until when: a date, or an event, that should prompt a second look.
Those five answers are what put a decision on the record. They apply to the formal decisions your board approves and to the everyday ones your analysts make, such as closing an alert, trusting a domain or ruling out a technique. Former Gartner analyst Anton Chuvakin says a SOC makes hundreds of those everyday decisions a week and throws almost all of them away.
Context of Record vs. Audit Trail
An audit trail shows what happened, when it happened and who authorized it. It’s how you prove an action took place, and investigations and audits depend on it.
A context of record adds the reasoning. It shows why a decision was made, what it rested on and how long that reasoning holds. Six months later, an audit trail can tell you that someone closed an alert. A context of record can tell you whether closing it still makes sense.
Context of Record vs. Risk Register
A risk register is the formal list of risks an organization has identified, with an owner, a rating and a treatment decision for each one. It’s where formal risk acceptances live, often with a review date, and for formal risk it does the job well.
Everyday decisions like allowlist entries and closed alerts never reach the register. The register also sits apart from the threat intelligence and exposure data each risk depends on, and every hand-off between tools is a point where context thins. A context of record keeps the formal decisions and the everyday ones together, next to the context behind them.
What Are the Three Layers of Security Context?
The three layers of security context are reference context, environmental context and decision context. The first two are well served by the tools in your stack, and the third tends to go missing. To see the difference, take a single domain on your allowlist, for example cdn.example.com.
Reference Context
Reference context is what the outside world knows about threats, including threat actors, their techniques, indicators of compromise, leaked credentials and vulnerability and exploit data. It lives in your threat intelligence platform and the feeds behind it.
For cdn.example.com, reference context tells you whether the domain appears in any known campaign. It’s also the layer that changes fastest, because new campaigns and exploits are published every day.
Environmental Context
Environmental context is what you run and what you expose, including assets, technologies, exposures, identities and configuration. It lives in your EASM and vulnerability management tools and in the inventories your teams keep.
For cdn.example.com, environmental context tells you which of your services load content from it. This layer changes too. Services launch, systems retire and configurations drift.
Decision Context
Decision context is what your team has decided and why, including what was triaged, trusted or accepted, by whom, until when and on what basis. It lives in exception fields, tickets, chat threads and people’s heads. That makes it the hardest of the three layers to find.
For cdn.example.com, the stack shows that the domain was added to the allowlist on 14 March 2025. It says nothing about who approved it, why or until when. The first two layers describe the world and your environment. The third describes what your team has decided, and no feed can sell you that.
Why a Context of Record Matters
A context of record lets your team build on decisions it has already made, explain them when someone asks and keep them when people leave. All three depend on capturing the reason at the moment of the decision, while the person who made it still remembers why.
Build on Past Triage Decisions
With a context of record, the next analyst to see an alert your team has already judged can find that judgment and start from there.
In Wakefield Research’s 2025 survey of 200 US SOC leaders for Devo, 84% of organizations reported that SOC analysts unknowingly investigate the same incidents several times a month or more. Sixty percent found duplicated investigations at least once a week. Each of those is a decision someone made once and then made again.
Know Who Accepted Each Risk and Why
Accepted risk can outlive its reason. A vulnerability is accepted because the system behind it is due to be retired, and then the retirement is delayed by a year. When the vulnerability starts being actively exploited, a context of record shows who accepted it, on what basis and when it was due for review.
Someone will ask for that answer. In-house it’s the board or an auditor, and at an MSSP it’s the client. With the reasoning on record, the decision can be explained, revisited or reversed by someone who understands why it was made.
Keep the Reasons When People Leave
When the person who made a decision moves on, the decision stays and the reason leaves with them. In 2011, Michael Nygard wrote that someone who inherits a past decision without its rationale has two choices. They can accept it blindly or change it blindly. He was writing about software, and your team faces the same choice with every allowlist entry and exception it inherits.
The 2025 SANS SOC Survey found that three to five years is the most common tenure for SOC staff. An allowlist entry or an exception can stay in place much longer than that. A context of record keeps the reasoning with the decision. The next person can read it before choosing to keep the decision or change it. For an MSSP, where analysts rotate between clients and shifts, that continuity is part of the service.
Risk Acceptance in Cybersecurity
Of all the decisions a security team makes, risk acceptance is the one that standards say the most about. It’s also the decision that leaves a known risk in place on purpose.
What Is Risk Acceptance?
Risk acceptance is a formal decision to live with a known risk for now. Some teams call it a risk exception. A team accepts a risk when a fix costs more than the exposure it closes, or when a fix isn’t possible yet.
ISO/IEC 27001:2022 asks risk owners to approve the treatment plan and accept the risk that remains (clause 6.1.3). FedRAMP’s Security Decision Record goes a step further. Providers explain the reason for any rule they don’t follow, and a senior official has to accept it.
Should a Risk Acceptance Expire?
Standards don’t require it, but a review-by date on each acceptance is good practice. ISO 27001 and FedRAMP both expect risks to be reviewed regularly, and the date is how a team makes sure that review happens.
Chuvakin argues that context in the SOC should carry an owner and a review date. “Unowned context,” he wrote, “is a future false negative with a countdown timer.” A risk acceptance with no date runs on the same timer, and the date can be a calendar date, an event or both.
A Risk Acceptance Example
An acceptance for an exposed admin interface on a legacy system might look like this.
- What: accept the exposed interface until the system is retired.
- Who: the head of infrastructure.
- Why: retirement is planned for next year, and an IP allowlist limits who can reach the interface.
- How: an external scan confirmed the allowlist holds.
- Until when: 31 March, or as soon as exploitation is reported.
The last line does the most work, because it ties the decision to the threat picture as well as the calendar. If exploitation is reported in February, the acceptance comes up for review in February.
Which Past Decisions Would New Threat Intelligence Change?
When new threat intelligence arrives, the obvious question is what it means for your assets. A context of record lets your team ask the inverse as well. Which of our past decisions does this change?
It might be a new exploit for a vulnerability you accepted last year, or a threat actor that starts targeting the supplier whose domain you trusted. It might be an advisory about a technique your team once decided wasn’t a concern. You can only find those decisions if each reason sits next to the intelligence that could change it. Then your team can revisit a decision before an attacker tests it. That’s preemptive cybersecurity applied to your own decisions.
If an advisory arrived tomorrow, could your team list every decision it touches? It’s the question we’ve been building around at Zynap, and we’ll have more to share on it soon.