Monthly Vulnerability Reviews
Overview
Section titled “Overview”A monthly vulnerability review is a scheduled session where you work through open vulnerabilities, decide what to do with each one, and assign owners. Forty-five minutes once a month is enough for most teams.
Fencer’s Vulnerability Review workflow is built for this. It captures a snapshot of matching vulnerabilities, presents them one at a time, records each decision, and stores the completed review as evidence that the review took place.
On Home, the recommended action Run a vulnerability review appears when no review is in progress and none has completed in the last 30 days. It opens Vulnerabilities → Reviews.
Why run a monthly review
Section titled “Why run a monthly review”Without a regular cadence, findings sit in Slack or a ticket backlog until the next audit, when someone has to triage weeks of work in a sprint.
A monthly review keeps that from happening:
- Every in-scope finding gets an explicit decision: fix it (with an owner and due date), defer it with a review date, or accept the risk and record why.
- The completed session is the evidence. SOC 2 CC1.2 requires ongoing oversight. ISO 27001 Clause 9.3 requires documented management reviews. A finished Fencer review includes who acted, what they decided, and when.
- You build that evidence as you go instead of assembling it from chat logs before an audit.
For most teams of 10 to 100 people, monthly is frequent enough. If you have a large unreviewed backlog, run the meeting every two weeks until the queue fits in 45 minutes, then switch to monthly.
Prerequisites
Section titled “Prerequisites”- An active Fencer organization with open vulnerabilities to review.
- The
vulnerabilities:editability to start a review. See Roles and Permissions.
How it works
Section titled “How it works”When you start a review, Fencer snapshots the vulnerabilities that match your filters. Findings discovered after that point are not added. They wait for the next review.
The queue shows one vulnerability at a time. You can assign an owner, ignore it with a reason, defer it, create a Jira or Linear ticket, or start a fix. Those decisions apply to the live vulnerability and are stored on the review.
Reviews have four statuses: Open, In progress, Completed, and Cancelled. Completing a review keeps it as the record for that period. Cancelling stops the session but does not undo decisions already applied. The cancelled review stays in the list.
Vulnerability Review is separate from Fencer triage (an automated true or false positive classification) and from User Access Reviews.
Usage / Configuration
Section titled “Usage / Configuration”Starting a review
Section titled “Starting a review”- Open Home and click Run a vulnerability review, or go to Vulnerabilities → Reviews.
- Click Start New Review. If you have never run a review, the empty intro also offers Review critical & high and Review all open.
- Set the title, filters, and assignee, then start. Fencer opens the queue.
Working the queue
Section titled “Working the queue”Decide on the current finding and move to the next. The queue advances automatically. You can skip items. Skipped findings are recorded as skipped.
Keyboard shortcuts (when the review has focus):
| Key | Action |
|---|---|
↓ / ↑ | Next / previous finding |
A | Assign |
I | Ignore (then 1–7 for a reason) |
D | Defer (reason, then a duration) |
F | Start a fix |
J / L | Open or link a Jira / Linear ticket |
Cmd/Ctrl + Enter | Confirm ignore or defer |
Esc | Close the current panel |
Completing the review
Section titled “Completing the review”Complete the review when you are finished. Keep completed reviews. Auditors typically want proof that a review occurred. An empty backlog is not required.
How to run the meeting
Section titled “How to run the meeting”Use Fencer as the working surface. You still need a facilitator, a small attendee list, and a fixed agenda.
Who should be there
Section titled “Who should be there”- 10 to 30 people in the company: the person who owns security (often the CTO), the person who owns infrastructure, and engineers whose work produced findings since last month. Keep the group small.
- 30 to 100 people: add a champion on each engineering team to bring findings from their area.
Include at least one person who is not responsible for executing the controls under review.
A 45-minute agenda
Section titled “A 45-minute agenda”| Time | Section | What to cover |
|---|---|---|
| 10 min | Open items from last month | What got fixed, deferred (and to when), accepted as risk (and by whom), and what is still open |
| 20 min | Findings triage | New high and critical findings. For each: fix, defer with a review date, or accept the risk with rationale |
| 10 min | Surface area | New APIs, SaaS tools, cloud resources, or apps since last month |
| 5 min | Incidents and near-misses | Status only. If an incident has its own war room, do not let it take over this meeting |
| 5 min | Next actions | Every open item leaves with an owner, a priority, and a due date |
Start with what was fixed last month. That keeps the meeting a progress check instead of a list of open problems.
Share the agenda a day in advance. Pull the queue from Fencer rather than assembling it from other tools. Keep the meeting on the calendar even when the month is busy.
Examples
Section titled “Examples”When Home shows that a review is overdue:
- On Home, click Run a vulnerability review.
- On the Reviews intro, choose Review critical & high.
- Work through the queue in the meeting and complete the review when you are done.
When you have a large backlog:
- For the first month, run the review every two weeks and scope it to critical and high.
- When that queue fits in 45 minutes, switch to monthly.
Troubleshooting
Section titled “Troubleshooting”- Start New Review is missing — You need
vulnerabilities:edit. - The recommended action on Home is gone — It only appears when no vulnerability review is in progress and none completed in the last 30 days. Open Vulnerabilities → Reviews to start or resume one anyway.
- The queue is empty — Nothing matched the filters you picked. Widen them (for example from critical and high to all open).
- A finding I expected is not in the session — A review is a snapshot. Findings that appeared after you started, or that do not match the filters, wait for the next review.