Quarter four of a first year security program should deliver a review of what actually ran, a decision on what to keep or drop, continuous checks for the controls that matter most, and a year two plan built from evidence. It is a quarter for consolidation, not for adding a fifth new tool.
Start with a review, not a plan
Open the quarter by asking what ran all year. Pull the weekly review notes, the fix queue history, exception records and incident exercise actions. Three questions sort most of it:
- Which controls ran every week or month without prompting?
- Which ones stopped, and why?
- Which findings keep coming back in the same form?
A control that stopped usually had no owner, produced noise, or needed a skill the team lacked. Each reason has a different fix.
Turn the strongest checks into continuous ones
Some controls are worth checking all the time rather than once a quarter: multi-factor sign-in coverage, protected branches on production repositories, scanner coverage of new repositories, and open known exploited vulnerabilities. These are cheap to automate and expensive to discover broken during a customer review.
The demo below shows what continuous monitoring looks like on a dashboard. Click through and look at how a drift in one control is surfaced, rather than waiting for a manual check.
Try it yourself
Click through it at your own pace, or open it full screen.
Retire on purpose
Dropping something is a decision, not a failure. Write down what you dropped, why, and what would make you bring it back. It prevents the same debate next year and shows buyers that the program is managed.
Write the year two plan
Use a simple table.
| Question | Source of the answer |
|---|---|
| What is the biggest remaining gap? | Review, incident exercise, customer questions |
| What did customers ask for that you could not show? | Questionnaire log |
| What will growth in engineers change? | Hiring plan |
| What is the one outcome per quarter? | The owner, agreed with engineering leadership |
Keep to one outcome per quarter. A year two plan with eight goals tends to land on none.
Use a framework as a checklist, not a goal
OWASP's Software Assurance Maturity Model describes itself as risk driven and says there is no single recipe that works for all organizations. A year end review is a good moment to run a light assessment against it or against another framework you already use, and to treat the gaps as input, not as a score to maximize.
A short staffing check
Ask whether the owner role is still realistic. If the named person spends most of the quarter answering questionnaires, that is evidence for the next hire or for moving some work to automation. Evidence from your own year is a stronger case than a benchmark.
Safeguard's continuous monitoring, compliance and evidence automation, and policies and gates fit the continuous checks step. A free scan is a way to see how current coverage looks.
Quick check
Should year two repeat the same plan with bigger numbers?
No. Base it on the review. Keep what ran, fix what stalled, and add one new outcome per quarter.
Do we need an external assessment at the end of year one?
Not automatically. Decide based on customer demand and on what the review shows. A lighter self assessment is a fine start.
Sources
Last reviewed: 19 October 2026.
