Keep a simple log of security decisions and approved exceptions

TL;DR — Use one shared folder, one decision log file, and one exception tracker file. The key habit is to record each security decision in a fixed template and give every exception an owner and expiry date; if you do only one thing, add an expiry date to every exception so it gets reviewed. Reading time: ~5 min

Goal

When you are done, your team will have a simple, shared security record that anyone can open and answer three questions quickly: what decision was made, why it was made, and which exceptions are temporarily allowed with an owner and review date.

Prerequisites

• A shared document tool your team already uses, such as Google Drive, Microsoft 365, Notion, Confluence, or a Git repository
• Edit access to create a folder/page/database in that tool
• The names of the people who can approve security decisions
• Your company or customer name to put in the template
• A list of current known exceptions, if any, such as "MFA not enabled for legacy VPN" or "production database backups not yet encrypted"
• Optional: spreadsheet software if your document tool does not support tables well

Steps

Step 1: Create one shared location for the record

Use your existing shared workspace. Create a folder or page called exactly:

Security Decisions and Exceptions

If you use a dashboard-style document tool, use its create path. Examples:

Google Drive → New → Folder → Security Decisions and Exceptions
Microsoft 365 SharePoint/OneDrive → New → Folder → Security Decisions and Exceptions
Confluence → Create → Page → Title: Security Decisions and Exceptions
Notion → New Page → Title: Security Decisions and Exceptions

What you should see when this succeeds: a shared location exists with the exact title "Security Decisions and Exceptions" and your team can open it.

Step 2: Create the security decision log file

Inside that shared location, create a document named exactly:

security-decision-log.md

Paste this exact content into the file:

# Security Decision Log

Owner team: <your company or customer name>
Approvers: <name 1>, <name 2>
Last reviewed: <YYYY-MM-DD>

## How to use this file
- Add one entry per security decision.
- Use a new ID in the format SD-001, SD-002, SD-003.
- Keep the status as Proposed, Approved, Rejected, or Superseded.
- If a decision allows temporary risk, add a matching row in the exception tracker.

---

## SD-001: Example entry
- Date: 2026-10-30
- Status: Approved
- Decision owner: <person or team>
- Approver: <person>
- System/service: <system name>
- Decision: Require multi-factor authentication for all admin accounts.
- Reason: Admin accounts can change production settings and need stronger login protection.
- Alternatives considered: Password-only login.
- Risk if not done: Account takeover could lead to service disruption or data exposure.
- Related exception: EX-001
- Review date: 2027-01-31
- Evidence link: <URL to ticket, screenshot, or policy>

What you should see when this succeeds: a document opens with a heading called "Security Decision Log" and one example entry named "SD-001".

Step 3: Create the exception tracker file

In the same shared location, create a second file named exactly:

security-exception-tracker.csv

Paste this exact content into the file:

Exception ID,Status,System/Service,Exception summary,Risk level,Reason,Compensating control,Owner,Approver,Date approved,Expiry date,Review date,Related decision,Evidence link
EX-001,Open,Legacy VPN,MFA not enabled for 2 contractor accounts,High,Legacy client does not support MFA,Restrict access to office IP addresses and review login logs weekly,IT Manager,Security Lead,2026-10-30,2026-12-31,2026-11-30,SD-001,https://example.com/ticket/123

If your tool prefers tables, create a table with these exact column names:

What you should see when this succeeds: a spreadsheet or table exists with columns for owner, approver, expiry date, and related decision.

Step 4: Add your first real security decision

In security-decision-log.md, copy the example block and replace it with your first real decision. Use the next available ID. For example:

## SD-002: Encrypt database backups at rest
- Date: 2026-10-30
- Status: Approved
- Decision owner: Operations
- Approver: Security Lead
- System/service: Production database backups
- Decision: Enable encryption at rest for all production backup storage.
- Reason: Backups contain customer data and should remain protected if storage is accessed by an unauthorized party.
- Alternatives considered: Restrict access without encryption.
- Risk if not done: Backup exposure could disclose customer data.
- Related exception: EX-002
- Review date: 2027-01-31
- Evidence link: https://example.com/tickets/backup-encryption

What you should see when this succeeds: the file contains a real entry with a unique ID like SD-002 and a review date.

Step 5: Add any temporary exception with an owner and expiry date

In security-exception-tracker.csv, add one row for each temporary exception. Use exact values in the same column order. Example:

EX-002,Open,Production database backups,Backups stored unencrypted until migration completes,High,Current backup target does not support encryption,Restrict backup bucket access to backup service account only and review access logs weekly,Operations Manager,Security Lead,2026-10-30,2026-11-30,2026-11-15,SD-002,https://example.com/tickets/backup-migration

What you should see when this succeeds: each exception has a status, owner, approver, review date, and expiry date.

Step 6: Add a simple monthly review reminder

Use your calendar tool and create a recurring event with these exact values:

Title: Review security exceptions
Frequency: Monthly
Duration: 30 minutes
Attendees: exception owners and approvers
Description: Open the file "security-exception-tracker.csv" and update Status, Review date, and Expiry date. Close any exception that is no longer needed.

Common menu paths:

Google Calendar → Create → Event
Outlook Calendar → New event

What you should see when this succeeds: a monthly calendar event appears with the title "Review security exceptions".

Step 7: Set a simple naming rule so records stay searchable

At the top of the shared folder or page, add this exact note:

Naming rule:
- Security decisions use SD-001, SD-002, SD-003
- Exceptions use EX-001, EX-002, EX-003
- Every exception must link to a decision ID
- Every exception must have an owner and expiry date

What you should see when this succeeds: anyone opening the shared location can see the naming rule before adding new records.

Verify it works

Check these four things end to end:

1. Open the shared location and confirm both files exist:

security-decision-log.md
security-exception-tracker.csv

1. Open security-decision-log.md and confirm there is at least one real entry with these fields filled in:

Date
Status
Decision owner
Approver
Decision
Reason
Review date

1. Open security-exception-tracker.csv and confirm every open exception has values in these columns:

Owner
Approver
Expiry date
Review date
Related decision

1. Open your calendar and confirm there is a recurring monthly event named:

Review security exceptions

Expected result: a teammate can answer "what did we decide?" and "what temporary risks are still open?" by opening one shared location without asking anyone else.

Common pitfalls

Using one document for everything with no IDs

Mistake: writing free-form notes in chat or meeting minutes without SD- and EX- IDs.

Symptom: nobody can tell whether an exception belongs to a real approved decision.

Fix: add IDs in the exact formats SD-001 and EX-001, then put the related ID in both files.

Recording exceptions with no expiry date

Mistake: adding "temporary" exceptions but leaving the expiry date blank.

Symptom: the exception stays open for months because no review is triggered.

Fix: enter a literal date in YYYY-MM-DD format in the Expiry date column for every open exception.

Listing a control but not an owner

Mistake: writing a good compensating control (temporary risk reduction) but not naming who must do it.

Symptom: the action does not happen because everyone assumes someone else owns it.

Fix: fill in the Owner column with one person or one team name, not "TBD".

Approving in chat but not updating the log

Mistake: a manager says "approved" in email or chat, but the files are not updated.

Symptom: during review or audit, the team cannot show when approval happened.

Fix: copy the approval date and approver name into the decision log and exception tracker the same day.

Closing the technical issue but leaving the exception open

Mistake: the underlying problem is fixed, but the exception row still says Open.

Symptom: your tracker overstates current risk and wastes review time.

Fix: change Status to Closed and add the closure evidence link in the same row.

Storing the files where only one person can edit them

Mistake: the record lives in a personal drive or private workspace.

Symptom: updates stop when that person is away or leaves the project.

Fix: move the folder to a shared team location and grant edit access to the approvers and owners.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.