A quarterly security review for a small team is a 60 minute meeting with five agenda items: last quarter's actions, exposure changes, access, incidents and near misses, and next quarter's two or three priorities. Keep a one page record. Nobody needs slides.
Why a quarterly meeting at all
Weekly and monthly routines handle alerts and chores. A quarterly meeting is where you step back and decide whether the routines still fit. New services appear, a customer asks new questions, a tool stops being used. Without a fixed time to look up, those changes go unexamined.
For comparison, the monthly checklist is about maintenance. The quarterly review is about direction.
Who attends
The engineering lead, one or two senior engineers, whoever owns infrastructure, and a founder or product lead who can trade security work against feature work. Four to six people is enough. Rotate the facilitator so the habit does not depend on one person.
The agenda
| Block | Minutes | Question to answer |
|---|---|---|
| Last quarter's actions | 10 | What did we commit to, and what did we finish? |
| Exposure changes | 15 | What new services, repositories, vendors or data did we add? |
| Access and accounts | 10 | Did the access review find anything? Any admin roles to cut? |
| Incidents and near misses | 15 | What happened or almost happened, and what did we learn? |
| Next quarter | 10 | What are the two or three things we will do, and who owns each? |
Hold the five blocks to their times. If one overruns, schedule a follow up rather than eating the others.
Prepare in 20 minutes
Before the meeting, one person collects four things: the open items from the risk list, a list of new repositories and services, the results of the last access review, and any incident notes. Put them in one document. The meeting then reviews facts instead of recalling them.
If you keep a risk register, bring it. Close finished rows, re-date deferred ones, and add anything new.
Choose priorities with a rule
Small teams fail by choosing eight priorities and finishing none. Pick no more than three. Choose by asking which item would hurt most if it were exploited, and which can be finished within the quarter. Reserve room for it in sprint planning, or it will lose to features.
The one page record
Write the date, attendees, decisions, owners and due dates. Store it with your engineering docs. Four of these a year is a respectable evidence trail for buyers and auditors, and it costs a few hours.
Common mistakes
Turning it into a status report. Inviting too many people. Setting priorities without owners. Skipping a quarter because things are busy, which is exactly when drift happens.
Where Safeguard fits
Safeguard can cover the dependency side of this work: SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Click a finding and look at how status and ownership are tracked, which is the view you would bring to the exposure item.
Quick check
Can we combine this with an engineering retro?
You can, if security gets its own protected block. Otherwise it is the first item cut.
What if nothing happened this quarter?
Then the meeting is short. Still review exposure changes, because new services are where gaps hide.
Last reviewed: 19 October 2026.
