Work that can usually wait until year two includes a formal risk register, large tool suites, red team exercises, and mapping to several frameworks at once. Work that cannot wait is the baseline: a named owner, an inventory, multi-factor sign-in, protected branches, and a fix routine. Defer by decision, with a date to revisit.
Why deferring is a skill
A first year has limited capacity. Every item you add displaces another, so the useful question is not "is this good?" but "what breaks if we do this next year instead?". Many valuable practices are better after the foundations exist, because they depend on the inventory and the routines.
A decision table
| Item | Can it wait? | Reason | Revisit when |
|---|---|---|---|
| Owner, inventory, access baseline | No | Everything depends on them | Now |
| Review and checks on the code path | No | Cheap and central | Now |
| A fix routine with owners | No | Without it findings pile up | Quarter two |
| Basic incident contacts and one exercise | Mostly no | Incidents do not wait | Quarter three |
| Formal risk register | Yes, in most cases | A short list of top risks serves first | After year one review |
| Broad red team exercises | Usually yes | Hard to fix findings before basics exist | When baseline is stable |
| Several frameworks at once | Yes | Pick one that buyers recognize | When a deal needs it |
| Large integrated tool suites | Usually yes | Process matters more than breadth | After a gap review |
| Advanced detection engineering | Often yes | Needs logging and staff first | When you have a rota |
The table is a starting position. A company handling regulated data may move items up.
Two notes on the "no" items
CISA's performance goals list third party validation, such as penetration tests, bug bounties and tabletop exercises, as a practice that tests defenses. That supports doing at least one exercise early, and does not mean every form of validation belongs in year one. A tabletop is cheap and fits quarter three. A full red team is another matter.
On the other hand, CISA also recommends that organizations monitor the Known Exploited Vulnerabilities catalog and prioritize listed items. That is low cost and does not need to wait.
How to defer well
- Write the deferral down. Name the item, the reason, and the review date.
- Set a trigger. For example, "revisit the risk register when we pass a stated headcount or sign a regulated customer".
- Give an interim measure. A one page list of top risks stands in for a register.
- Tell leadership. A deferral is a risk decision, and it belongs to them to know about.
What happens if buyers ask earlier
Customers sometimes ask for things you deferred. Answer truthfully: what you do today, what is planned, and when. If the same request comes from several buyers, it is evidence to move the item up. See the post on stopping customer requests from derailing the roadmap.
Avoid the opposite trap
Deferral can turn into avoidance. Put every deferred item on the year two plan so that the list gets reviewed rather than forgotten.
Safeguard's compliance and evidence automation and asset discovery cover the baseline, which is the work that should not wait. Begin with the free scan.
Quick check
Is it wrong to skip a risk register in year one?
Not usually. A short, reviewed list of top risks works for a young program. Add structure when scale or a customer demands it.
What is the one thing that must not wait?
Ownership. A named person with authority to decide.
Sources
- CISA Cybersecurity Performance Goals (archived page that points to a newer version)
- CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities
Last reviewed: 19 October 2026.
