Security Evidence & Accountability: Who Actually Accepts the Risk?

Who accepts residual risk, what proves remediation, and how to reconstruct why a security issue was fixed, mitigated, deferred or accepted months later.

Zigmārs AncveirsTechnology Leader in FinTech & RegTech · Cybersecurity & Ethical HackingPublished: 26 September 2026Reviewed: 26 September 202614 min

Introduction

A security finding is open.

Engineering develops a fix.

The ticket moves to Resolved.

A red dot disappears from the management dashboard.

Has the risk been resolved?

Not necessarily.

It may be that:

the fix has not reached production;
remediation covers one symptom but not the root cause;
a compensating control covers only part of the affected scope;
nobody retested the security condition;
significant residual risk remains;
no authorised person consciously accepted that residual risk;
or Closed simply means the workflow ran out of states.

This is the difference between security activity and defensible security governance.

An organisation is not accountable merely because it has:

policies;
a risk register;
a SOC;
penetration tests;
CVD;
an incident-response plan.

It should also be able to reconstruct a material decision:

What did we know, what risk did we identify, what did we do, what proved the result, and who accepted what remained?

That is the security evidence and accountability problem.

Cybersecurity governance is increasingly a management responsibility

NIS2 makes the governance boundary unusually explicit.

Article 20 requires Member States to ensure that management bodies of essential and important entities approve the cybersecurity risk-management measures used to comply with Article 21, oversee their implementation and, subject to national liability rules, can be held liable for infringements.1

That matters because cybersecurity risk is no longer framed as merely:

the CISO's technical problem.

DORA is even more explicit for financial entities. The management body must define, approve, oversee and be responsible for implementation of the ICT risk-management framework, bears ultimate responsibility for ICT risk, and sets the entity's ICT risk-tolerance level.2

Latvia provides a national example in the same general direction. Section 25 of the National Cybersecurity Law states that the head of the entity ensures and is responsible for cybersecurity governance, while the cybersecurity manager implements and supervises cybersecurity measures.4

These legal models are not identical.

Their common governance lesson is:

appointing a security specialist does not make organisational accountability disappear.

“Owner” is dangerously ambiguous

A security workflow often contains one field:

Owner: Alice

That can conceal several different roles.

Finding owner

The person coordinating the individual finding.

Remediation owner

The person or team implementing the treatment.

Control owner

The person accountable for design and operation of a control.

Risk owner

The person accountable for the affected business/service risk and able to make treatment decisions within delegated authority.

Decision authority

The person or governing body empowered to approve a specific risk acceptance, exception or escalation.

One person may sometimes occupy more than one role.

The roles should still remain conceptually separate.

The most important boundary is:

the person who implemented the fix should not automatically become the sole authority that proves the fix effective and accepts the remaining business risk.

NIST CSF 2.0 elevates governance and accountability

The NIST Cybersecurity Framework 2.0 added a dedicated GOVERN Function so cybersecurity strategy, roles, responsibilities, authorities, policy and oversight are treated as first-class elements of risk management.5

Within the CSF Core, GV.RR covers Roles, Responsibilities, and Authorities. GV.RR-01 states that organisational leadership is responsible and accountable for cybersecurity risk, while GV.RR-02 calls for cybersecurity risk-management roles, responsibilities and authorities to be established, communicated, understood and enforced.6

NIST does not prescribe one universal RACI chart.

The outcome matters:

Can the organisation demonstrate who was authorised to decide what?

Evidence is not the same thing as documentation

An organisation can have thousands of documents and still have poor evidence.

Consider MFA.

A policy says MFA is mandatory.
A screenshot shows that MFA can be enabled.
A configuration export shows that it is enabled for 78% of administrators.
An authentication log shows one privileged account was not challenged.
A penetration test demonstrates a recovery-path bypass.

Every artifact says something.

They do not support the same claim.

A useful evidence record therefore needs:

Without a claim-to-evidence link, the organisation is collecting files.

Not assurance.

claim
→ source
→ scope
→ timestamp
→ integrity/provenance
→ limitations
→ expiry / review condition

Evidence can legitimately conflict

A mature governance system should be able to represent:

CONFLICT

For example:

the control owner says backups are tested;
the scheduler shows successful backup jobs;
the restore exercise fails;
the continuity plan still assumes a two-hour RTO.

The correct conclusion is not:

Three positive artifacts versus one negative one: PASS.

It is:

Evidence is contradictory; control effectiveness is not sufficiently demonstrated.

Security governance should preserve supporting, contradictory, stale and missing evidence.

Otherwise the evidence base becomes structurally optimistic.

“The control exists” is not the same as “the control works”

I use a simple analytical scale:

This is not an official NIST or ISO maturity model.

It solves a practical semantic problem.

“MFA policy exists” is not equivalent to:

privileged-account takeover risk is effectively controlled.

Implementation, operation and effectiveness evidence sit between those statements.

DESIGNED
→ the control exists in design

IMPLEMENTED
→ it exists technically or procedurally

OPERATING
→ repeated evidence shows it is being executed

EFFECTIVE
→ testing demonstrates the intended risk reduction

CONTINUOUSLY ASSURED
→ monitoring/testing supports sustained effectiveness

Residual risk should not be one word: “Accepted”

Controls rarely reduce risk to zero.

Residual risk therefore needs a meaningful description.

A defensible residual-risk statement should describe:

the remaining scenario;
remaining potential consequence;
control limitations;
unresolved uncertainty;
compensating controls;
monitoring;
owner;
decision authority;
reassessment date.

Weak:

Stronger:

That is a decision record.

Not a coloured cell.

Residual risk: Medium
Status: Accepted

Scenario:
privileged session theft remains possible if
hardware-backed MFA is bypassed through an unmanaged recovery flow.

Current controls:
- phishing-resistant MFA for administrators
- conditional access
- privileged-session logging

Known limitation:
legacy recovery path remains active for 14 accounts.

Decision:
temporary acceptance until migration completion.

Owner:
business service owner

Expiry:
2027-01-31

Reassessment triggers:
- recovery-path abuse
- new exploit technique
- migration delay

Risk acceptance is an action, not a status label

Accepting risk means:

We understand what remains and consciously continue the activity under defined conditions for a defined period.

A credible acceptance record therefore needs at least:

exact scope;
residual risk;
rationale;
alternatives;
decision authority;
compensating controls;
duration;
monitoring;
reassessment triggers;
expiry.

Without expiry, a temporary exception can quietly become architecture.

Without triggers, an old assumption survives after reality changes.

Security advises; the business cannot hide behind Security

The security function can establish:

This vulnerability permits cross-tenant data access.

It may also assess:

exploitability;
evidence quality;
control effectiveness;
technical remediation options.

But a statement such as:

We will continue this business service for four months with the remaining exposure.

is often a business/service risk decision.

Security can recommend.

The authorised risk owner accepts, rejects or escalates.

The reverse limitation matters too.

A business owner cannot simply state:

I accept the risk.

where law, policy or a non-waivable requirement does not permit that state.

Risk acceptance is not a mechanism for overriding every constraint.

NIST RMF illustrates evidence-based authorisation

NIST SP 800-37 Rev. 2 describes a structured Risk Management Framework in which controls are selected, implemented, assessed and monitored, while senior leaders receive the information needed to make risk-based authorisation decisions.7

The exact U.S. federal authorisation process is not the point here.

The useful structure is:

That is materially stronger than:

control implementation
→ assessment
→ evidence
→ risk decision
→ monitoring

control documented
→ approved

The remediation owner should not self-issue closure without evidence

A finding often ends like this:

Developer: fixed. Jira: Done.

But what was verified?

A defensible closure separates at least four things.

Remediation evidence

What actually changed?

code;
configuration;
release;
architecture;
compensating control;
system retirement.

Deployment evidence

Did the change reach the environment in which the vulnerability existed?

Verification evidence

Can the original security condition still be reproduced?

Residual-risk decision

What exposure remains, and who is authorised to accept it?

This is the same reason fix ready and verified closed are separate states in Coordinated Vulnerability Disclosure in Practice.

“Mitigated” and “Fixed” should not collapse into one state

Suppose a legacy administrative endpoint has weak authentication.

The organisation:

adds an IP allowlist;
leaves the endpoint in service;
delays authentication redesign until next quarter.

That may be a reasonable short-term treatment.

It is not the same thing as root-cause removal.

A useful status vocabulary distinguishes:

If all of them become Resolved, management reporting loses meaning.

FIXED
MITIGATED
WORKAROUND
RISK_ACCEPTED
DEFERRED
BLOCKED_EXTERNAL

“Closed” is not necessarily permanent

Security evidence ages.

A control tested one year ago may no longer support a claim after:

a major release;
cloud migration;
identity redesign;
supplier change;
business-process change;
new attack technique.

Closure therefore may require more than:

closed_at

It may also need:

valid_until;
review_at;
reassessment_trigger.

A finding can be verifiably closed for a particular version.

That is not a timeless claim that the vulnerability class will never return.

Reassessment triggers are part of the original decision

Risk decisions depend on assumptions.

Assumptions expire.

Typical triggers include:

a material incident;
repeated findings;
a newly available exploit;
control failure;
supplier change;
treatment delay;
material architecture change;
new legal obligations;
a change in risk tolerance.

DORA provides a concrete regulated example: the ICT risk-management framework is documented, periodically reviewed and continuously improved using lessons from implementation, major incidents, testing and audits.3

Governance is therefore not only the ability to make a decision.

It is the ability to recognise when the old decision no longer holds.

Auditability does not mean recording everything at maximum depth

Governance can become self-defeating.

If every low-risk finding requires a thirty-field record and fourteen approvals, the control system becomes more expensive than the risk.

Evidence depth should scale with:

materiality;
potential harm;
irreversibility;
regulatory consequence;
expected lifetime of the decision;
third-party impact.

The useful principle is:

proportionality reduces record depth; it does not remove accountability.

A minor risk may need a compact record.

A critical multi-year acceptance needs substantially more.

A Security Decision Record

For a material security decision, I would preserve something like:

This is not a NIS2, DORA or NIST mandated data model.

It is my proposed Security Decision Record.

decision:
  id:
  date:
  question:
  scope:

risk:
  scenario:
  affected_assets:
  inherent_or_current_risk:
  residual_risk:
  unknowns:

evidence:
  supporting:
  contradictory:
  missing:
  last_verified:

options:
  - fix
  - mitigate
  - avoid
  - defer
  - accept

decision:
  selected:
  rationale:
  conditions:
  authority:
  risk_owner:

treatment:
  remediation_owner:
  due_date:
  compensating_controls:

verification:
  method:
  verifier:
  result:

reassessment:
  review_date:
  triggers:
  expiry:

Why contradictory and missing evidence belong in the record

Decision history becomes unreliable if it stores only information supporting the selected outcome.

For example:

Keeping only the first line creates artificially clean governance.

Accountability requires uncertainty to remain visible.

Supporting:
WAF blocks known payload.

Contradictory:
manual testing bypasses the WAF with alternate encoding.

Missing:
no evidence for the mobile API path.

Exceptions and waivers need an end condition

Most waivers begin with a reasonable explanation:

Migration is not yet possible.

Two years later, the organisation may no longer remember why the exception exists.

A useful waiver record therefore includes:

waived requirement;
exact scope;
rationale;
compensating controls;
residual risk;
approver;
start date;
expiry;
monitoring;
closure criteria.

Repeated renewal is itself evidence.

The organisation may no longer have a temporary exception.

It may have structural design debt.

Outsourcing does not make final accountability disappear

A supplier may be responsible for:

a patch;
SaaS controls;
SOC operations;
cloud configuration;
penetration testing.

That does not mean the customer organisation can simply say:

The vendor accepted our business risk for us.

DORA makes the point explicitly in finance: the management body retains ultimate responsibility for ICT risk.2

The broader principle is useful elsewhere:

performance of a control can be outsourced; organisational accountability for the resulting business risk generally cannot be outsourced by declaration.

Contracts can allocate obligations and liability.

The organisation still needs to know what risk it has retained.

Management dashboards should expose decision quality

A conventional dashboard may show:

That is not useless.

It becomes much more meaningful when management can also see:

findings without an accountable owner;
overdue treatments;
findings marked mitigated rather than fixed;
closures without retest;
accepted risks approaching expiry;
stale effectiveness evidence;
recurring root causes after prior closure.

Examples of stronger management signals:

That turns a dashboard from inventory into governance.

Open vulnerabilities: 123
Critical: 4
High: 17

Critical findings without accountable owner
High findings overdue beyond accepted treatment date
Accepted risks expiring in 30 days
Closures without independent/risk-based verification
Controls with stale effectiveness evidence
Repeat root causes after prior closure

A security metric should point to a decision

“Patch compliance: 96%” sounds good.

Management still needs to know:

which 4% is missing;
whether it is internet-facing;
whether known exploitation exists;
whether compensating controls exist;
who accepted the delay.

A useful metric therefore carries:

Otherwise the number becomes decoration.

metric
+ population
+ exclusions
+ risk context
+ owner
+ action threshold

Accountability is not blame assignment

This matters culturally.

If accountability means:

find the person to punish,

people learn to:

hide uncertainty;
downrate findings;
avoid ownership;
document defensively;
close tickets to improve dashboards.

A more useful model is:

accountability = clear authority + reconstructable decision + observable outcome + ability to learn.

Personal or legal liability can of course exist in particular circumstances.

But routine governance should not be designed as a blame machine.

Its purpose is to prevent material risk from disappearing between functions.

A five-part security evidence chain

I reduce the model to five parts.

1. Evidence

What do we actually know?

2. Context

What does the evidence mean for the specific asset, service and organisation?

3. Decision

What was decided, why, and who had authority?

4. Outcome

What was actually implemented, and did it work?

5. Reassessment

What event or date makes us reconsider the decision?

When one link is missing, governance weakens.

The two most commonly under-designed links are Outcome and Reassessment.

Organisations document:

what we intended to do

better than:

whether it actually changed risk, and when that conclusion should be tested again.

Conclusion

Cybersecurity governance is not mature because an organisation has many control documents.

It is not mature because dashboards show few open findings.

It is mature when a material security decision can be reconstructed as:

evidence → context → authority → treatment → verification → residual risk → reassessment.

That changes the closing question.

Not:

Is the finding closed?

But:

What did we actually prove, who accepted what remained, and what will cause us to reopen the decision?

That is the difference between security administration and security accountability.

It is also the final step in the assurance cycle:

discover → understand → decide → remediate → verify → accept what remains → learn.

Frequently asked questions

Can a CISO accept residual risk?

It depends on delegated authority and applicable rules. Security may analyse and recommend treatment, but material business or service risk is often accepted by the relevant risk owner or higher decision authority rather than by the security function merely because it understands the technology.

Is a finding closed when the patch is written?

Not necessarily. The organisation should know whether the change reached the affected environment, whether the original security condition is no longer reproducible and what residual risk remains.

Can risk acceptance be indefinite?

Some risk decisions may legitimately be long-lived, but temporary exceptions and deferred remediation benefit from explicit expiry and reassessment triggers so an old assumption does not become an uncontrolled permanent state.

Does management approval require executives to understand exploit mechanics?

No. Management does not need to become a penetration-testing team. It needs sufficient, reliable and comprehensible evidence about the risk, alternatives, consequences and uncertainty to exercise its authority responsibly.

Can a vendor accept our risk?

A vendor can accept contractual obligations and responsibility for its own controls. That does not automatically remove the customer's governance accountability for its service and retained business risk.

Does auditability mean documenting every small decision at the same depth?

No. Record depth should be proportional to materiality, consequence, irreversibility and regulatory needs. Proportionality reduces detail; it does not eliminate ownership, decision authority or evidence.

Source status

Sources and legal status checked on 25 September 2026. The Security Decision Record, five-part evidence chain, control-effectiveness scale, waiver/closure fields and role distinctions are the author's analytical governance model. They are not a mandatory data schema under NIS2, DORA, NIST or Latvian law.

This article analyses cybersecurity governance, assurance and risk accountability. It is not individual legal, audit or supervisory advice.