A 45-minute monthly meeting is all it takes to manage security without a dedicated team, and it generates audit evidence as a byproduct.
Security scanner alerts are easy to ignore when there's no meeting forcing you to look at them. They land in Slack, sit in a ticket backlog, or end up in a spreadsheet that gets opened once a year when the auditor asks for it. Everyone knows the list exists. Nobody is sure whose job it is to do something about it.
For most startups, security works in cycles: automated tools scan continuously, findings accumulate, and the CTO (or whoever accidentally inherited the security role!) runs a triage sprint before the next audit. The backlog gets cleared, the evidence gets collected, and then the cycle resets. Nothing changes between audits because there's no structure to keep the work moving.
A 45-minute monthly security review meeting changes that, and you don't need a security team to run one. What you need is a structured agenda, a small group of people who own different parts of the stack, and a consistent cadence. Findings get decisions instead of sitting in a queue, action items leave the meeting with owners, and the minutes from that meeting turn out to be most of what your auditor wants to see anyway. This guide covers how to run a security review meeting.
The pattern is consistent enough that it has a name. Ryan McGeehan, who wrote Starting Up Security, describes it as the "recurring initiative trap": security activity spikes before audits and enterprise security questionnaires, then drops to near-zero in between. Teams rebuild from scratch each cycle because there's no institutional memory between reviews. The backlog doesn't disappear during the quiet period, it grows. As Bessemer Venture Partners notes in their startup security guide, playing catch-up later costs many times more in time, money, reputation, and distraction.
Findings surface in Slack, drift into Jira with a "someday" label, or make it onto a shared doc that nobody has bookmarked. Alert fatigue compounds things: when your scanner marks everything as critical, nothing gets triaged, because doing the triage right requires judgment and time that the sprint doesn't have room for.
Security ownership defaults to whoever is most technically senior, and that person is usually the CTO. A CTO carrying the security context solo is context-switching between roadmap decisions, hiring, architecture reviews, and CVE triage. It doesn't scale, and it creates a single point of failure for security knowledge at the organization.
A security review meeting is a scheduled, recurring meeting where a small group reviews open security findings, makes fix/defer/accept decisions, assigns owners, and documents the outcomes. That's the whole definition. It's not a training session, not a tooling demo, and not a postmortem.
It's also not a daily standup, which is too shallow for decision-making. It's not a quarterly audit prep session, which is too infrequent and carries the wrong framing: "audit prep" implies that security is something you do before an auditor shows up, not something you do to keep the business secure. And it's not an enterprise security committee, which assumes headcount and formality that most startups don't have and don't need. If you want a maturity model to calibrate against, OWASP's SAMM defines security governance at multiple levels, and the first level simply requires that security activities are tracked and reviewed at regular intervals. That's exactly what this meeting is.
The right-sized version for a company with 10 to 100 employees: 45 minutes, monthly cadence, run by whoever functionally owns security (probably the CTO). One facilitator, a fixed agenda, documented outputs. That's it. NIST CSF 2.0 added a dedicated Govern function as its sixth pillar, explicitly calling for ongoing cybersecurity risk management oversight. The security review meeting is that oversight in practice.
One exception to the monthly cadence suggestion: if you're starting from scratch with a large backlog of unreviewed findings, consider running biweekly for the first month or two to burn through the initial pile. Once you reach a steady state where the meeting isn't dominated by inherited backlog, shift to monthly. The goal is to get to a cadence where each meeting is manageable, not a marathon.
The attendee list is short: the CTO plus whoever owns infrastructure, plus any engineer whose work generated security-relevant findings since the last meeting (flagged PRs, new integrations, recent cloud configuration changes). Keep it small. If everyone is in the room, nobody feels accountable for anything specific.
Add a designated Security Champion per engineering team. Their job before the meeting is to surface findings from their area so the CTO isn't aggregating everything alone. A Security Champion doesn't need a security background: they need enough context to know what changed in their domain since last month and to flag anything that warrants the group's attention. This is how the meeting scales without scaling headcount.
One thing worth accounting for if SOC 2 or ISO 27001 is in scope: CC1.2 requires that oversight be exercised by a party capable of independent judgment. ISO 27001 Clause 9.3 goes further, mandating documented management reviews with specific agenda items and recorded outputs. In practice, for a small team, this means at least one attendee should not be the same person responsible for executing the controls being reviewed. A CTO reviewing changes an engineer implemented satisfies this. An engineer reviewing decisions the CTO made also satisfies this. The bar is lower than most teams expect.
Good preparation is what makes 45 minutes actually work. If the meeting starts with people orienting themselves to the current state of the backlog, you've lost a third of your time before anything gets decided.
When something comes up between meetings, whether it's a new finding, an issue someone flagged in Slack, or a risk you noticed while reviewing a PR, add it to the doc. Don't wait until two days before the meeting to reconstruct everything from memory. Recency bias is real: without the log, you'll over-index on whatever you saw yesterday and forget the thing from three weeks ago that actually matters more.
The agenda has five sections. The time splits below assume 45 minutes total. Adjust based on your backlog size, but don't let the meeting run longer than an hour.
Open items from last month (10 min). Start with what got fixed. This is intentional: leading with resolved items reframes the meeting as a progress check, not a crisis review. Security backlogs never hit zero, and if every meeting opens with "here's everything that's still broken," people stop wanting to show up. Acknowledge the wins first, then move to what got deferred (and to when), what was accepted as risk (and by whom), and what's still open without a status. Every item from last month's action log should have a status. If it doesn't, the meeting starts by establishing one. This section is accountability in practice: it creates the loop-closing mechanism that the rest of the meeting depends on.
Findings triage (20 min). Review new high and critical findings since the last meeting. For each one, make a decision: fix (assign an owner and a due date), defer (document the rationale and set a review date), or accept the risk (document who accepted it and why). Medium and low findings can be batched or handled asynchronously unless the facilitator flags something that warrants group discussion.
The three-decision framework is worth internalizing. Risk acceptance is legitimate, especially for a startup managing competing priorities. Undocumented risk acceptance is a different thing: it's a liability, and it's what auditors flag. The meeting is the forcing function for making the decision explicitly rather than by default.
Surface area review (10 min). What's new in your environment since the last meeting? New APIs exposed, new SaaS tools adopted, new cloud resources spun up, new apps built by contractors or internal teams. This is the part of the agenda that most guides skip, and it matters more now than it did two years ago. When anyone on the team can build and deploy an application, your attack surface grows faster than your security team (of zero) can track organically. A monthly inventory check catches the things that scanners can't flag because nobody told the scanner they existed. New APIs with no authentication, a shared Google Workspace that suddenly has public access, an internal tool a contractor shipped that's now handling production data. If you don't know it exists, you can't defend it.
Incidents and near-misses (5 min). If there was an actual security incident since the last meeting, this is where you cover status and progress. Not every meeting will have something here, and that's fine. When it does, keep it focused: what happened, what's the current response status, what's left to do. This section is reactive by nature, so keep it contained. If an incident is consuming significant time, it probably has its own war room and doesn't need to take over this meeting.
Next actions (5 min). Every open item leaves the meeting with an owner, a priority, and a due date. No exceptions. Items without owners don't get done. Items without due dates stay open forever, and then show up in the "open items from last month" section three meetings from now, still unresolved.
The most important thing is that everyone understands why the meeting is important, and feels like they are getting something useful from it. Make sure everyone has context before starting the meetings to know why they're being pulled from other work that might feel more important to the business. Your customers have just as high an expectation that your systems are secure, as they do that you'll ship that shiny new feature! However, if folks don't understand this, it's easy for folks to feel like it's just another checkbox or a waste of time.
So your meetings go quickly, a few days before the meeting, share the agenda so that folks can feel prepared and are not ambushed by questions when maybe security wasn't the top priority from the engineering team over the past month. An automated reminder to folks can help them remember to get items from last month done is useful as well. Have the list of tickets to go over in advance; nobody likes to watch someone struggle with Jira filters when they could be doing other things!
The regular schedule is as important as having everyone who needs to participate be there. Schedule the meetings adjacent to one of your other meetings, or just swap it out for one of your other meetings altogether! But regardless, it stays on the calendar. The cadence is the key. If you let it drop one month, it's easy to skip it the next, and before long you're back into the original cycle.
Though security is a part of everyone's job, people can easily feel resentful or disconnected if it is all work and no reward. Use your meetings to recognize and reward teams and individuals who contributed over the past month. Engineering teams appreciate recognition for fixing that gnarly security bug, or that staying late to apply that urgent security patch. If your company allows it, even a small gift is a great motivator for your top contributors to the security backlog.
Your customers expect your systems to be secure. Your enterprise prospects require proof. Your team deserves to work on a product they're confident in. Security isn't overhead, it's foundational to the business you're building. A 45-minute monthly meeting with a fixed agenda, documented decisions, and owners for every open item gives security the dedicated space it needs. Run it consistently, and security becomes part of how you operate instead of something you scramble to prove once a year.
Fencer gives you the single screen to run this meeting from. A unified view of your vulnerabilities across code, cloud, and infrastructure, prioritized so you know which findings to focus on first, with attack surface monitoring that keeps up as your assets evolve. No more stitching together outputs from six tools before the meeting starts. See how it works →
Monthly is the right cadence for most startups with 10 to 100 employees. It's frequent enough to keep findings from piling up and infrequent enough that the meeting doesn't become a burden. If you're starting from scratch with a large backlog, consider running biweekly for the first month or two until you reach a steady state, then shift to monthly.
Whoever functionally owns security, which at most startups is the CTO or a senior engineer. The facilitator doesn't need a security background. They need enough context to pull the findings list, set the agenda, and keep the meeting focused on decisions rather than discussion. At companies with 30 or more employees, adding a Security Champion per engineering team helps distribute the prep work.
Audit prep is reactive: a sprint before the auditor shows up to collect evidence and close out open items. A security review meeting is continuous: a monthly cadence where findings get triaged, owners get assigned, and decisions get documented as they happen. The key difference is that a well-run security review meeting generates audit evidence as a byproduct, so the scramble before the audit becomes unnecessary.
Yes. ISO 27001 Clause 9.3 explicitly requires documented management reviews covering prior actions, risk assessments, and improvement decisions. SOC 2 CC1.2 requires evidence of ongoing oversight by a qualified party exercising independent judgment. Meeting minutes with attendee lists, documented decisions, and assigned action items satisfy both requirements.
A 45-minute meeting breaks down into five sections: open items from last month (10 min), new findings triage (20 min), surface area review covering new assets and integrations (10 min), incidents and near-misses (5 min), and next actions with owners and due dates (5 min). Every finding should leave the meeting with one of three decisions: fix it, defer it with a review date, or accept the risk with documented rationale.
