ADR Security Decision-Making

Decisions That Don't Evaporate

This topic works best as a practical framework: clear enough for decision-making and concrete enough for execution.

In ADR Security Decision-Making, the goal is to document choices that teams can execute consistently and repeatably.

This keeps this chapter from being theory and makes it a usable compass for consistent execution.

Immediate measures (15 minutes)

• Use this page to prioritize measures and convert them into backlog items.
• Link each measure to an owner, deadline, and demonstrable evidence.
• Repeat periodically based on risk, changes, and incident lessons.

Why this matters

The core of ADR Security Decision-Making is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Why ADRs for security

Without ADR:

• arguments disappear over time;
• exceptions become "normal";
• audit trail is missing during incidents.

With ADR:

• trade-offs are transparent;
• ownership remains clear;
• you can revise in a controlled manner.

When is a security ADR required?

Always create an ADR for:

• new trust boundary;
• change in identity or privilege model;
• exceptions to baseline controls;
• choice of cryptography/key management;
• onboarding of critical vendor/component.

ADR template (security)

Use the following format:

# ADR-XXX: [Title]

## Context
- Which business objective and which assets?
- Which threats and compliance requirements apply here?

## Decision
- What exactly do we choose?
- Scope, preconditions, validity period.

## Considered alternatives
- Option A: ...
- Option B: ...
- Why rejected/chosen?

## Security impact
- Confidentiality / Integrity / Availability impact
- New risks and mitigating controls

## Detection and evidence
- Which logs/metrics demonstrate effectiveness?
- Which tests or checks are required?

## Governance
- Owner
- Review date
- Expiration date / reassessment

Quality decision rules

An ADR is usable when:

• risk is explicitly and measurably described;
• alternatives have been weighed;
• compensating controls are identified;
• review and expiration dates are included;
• owner and decision authority are documented.

Example: exception to segmentation

Context: legacy system requires temporarily broad network access.
A good ADR choice contains at minimum:

• time-bound exception;
• additional monitoring/alerting;
• restriction on source-destination combinations;
• plan and deadline for structural solution.

Bad choice: "temporarily opened" without end date and without detection.

Integration in change process

Link ADRs to:

• change tickets;
• pull requests for policy/config;
• risk register;
• monthly architecture review.

This keeps security decision-making from being a documentation exercise and makes it part of delivery.

Summary

ADRs make security architecture governable. It's not the amount of documentation that counts, but the quality of explicit trade-offs, measurability, and reassessment.