Every engineering organization I have seen has a risk register somewhere. Most of them are dead. The document exists, the rows are filled in, the file is on a shared drive, and nobody has touched it in nine months. It comes back to life two weeks before the next compliance audit, gets a quick scrub, and goes back into hibernation.
The pattern is not unique to any one company size or industry. It shows up in startups with fifteen engineers and in mid-sized companies with two hundred. The root cause is the same in both. The register was built for a single audience that only shows up once a year, so it does not develop the muscle of being used on a normal Tuesday.
Photo by Walls.io on Pexels
The compliance-driven origin story
Most risk registers start life as a deliverable for a SOC 2 or ISO 27001 readiness exercise. A consultant or an internal compliance lead asks for one. The engineering team produces it under time pressure, often by copying a template and renaming the rows to fit the stack.
The result usually passes the audit. The problem is that the register was never connected to the decisions engineering actually makes. It does not appear in sprint planning. It does not show up when budget allocation comes around. It is not referenced when a new vendor is evaluated. The document and the day job operate in completely separate universes.
The International Organization for Standardization frameworks that drive most of these registers do not require this disconnection. They describe the artifact, not how to integrate it. The integration is what teams miss.
The three signs your register is dead
A dead risk register has three reliable symptoms.
The first is that rows have no recent updates. If the most recent edit on most rows is older than your most recent quarterly board update, the document is not being maintained. The presence of an "edited yesterday" timestamp on the document header is not enough; check whether the rows themselves have moved.
The second is that owners listed on rows are no longer at the company, or no longer in the role that matches the row. A row that says "owner: previous CTO" is a row that nobody is acting on.
The third is that the register is never referenced in meetings outside of compliance reviews. If you cannot remember the last time someone in an engineering planning meeting said "we should look at the risk register on that," the register is not part of how the team makes decisions.
What a living register looks like
A living register has four characteristics that a dead one lacks.
It has fewer rows. Most living registers have between fifteen and thirty rows. A register with eighty rows is almost certainly being maintained as a checklist exercise rather than as a decision tool. When teams audit the rows for actual relevance, the count collapses fast.
It has concrete titles. "Cybersecurity risk" is not a row. "Single point of failure on the Stripe webhook receiver for billing reconciliation" is a row. The first one cannot be assigned. The second one becomes an actual project on someone's quarterly plan.
It has mitigation costs attached to the high-impact rows. Without costs, the register cannot be the input to a budget conversation. With costs, leadership can do the actual tradeoff math. The Wikipedia risk management article frames this as the heart of the discipline, even though most operational implementations skip it.
It has a real review cadence with named participants. Monthly engineering touch-up, quarterly leadership review, annual compliance reconciliation. Each layer has a calendar invite and a known short list of attendees.
Photo by Christina Morillo on Pexels
The Monday morning test
A simple test for whether a register is alive: can a CTO open it on a Monday morning, find a row that explains why they should care about a specific problem this week, and use the row to decide what to spend Tuesday on?
If the answer is no, the document is paperwork. If the answer is yes, it is doing the job it exists to do.
This test is harder to pass than it looks. It requires that the rows be specific enough to map to current work. It requires that the impact statements be in language that a non-engineer can read. It requires that the owners be people who can actually take action without escalating through three layers.
The National Institute of Standards and Technology cybersecurity frameworks emphasize this kind of usability in their documentation, though the practical guidance for integrating the register into real engineering decision-making is largely left to the implementer.
What revival actually looks like
Reviving a dead register is not the same as starting one from scratch. You usually have most of the raw material already; the problem is that it is in the wrong shape.
The revival pattern that works:
Schedule two ninety-minute sessions in the same week. The first session is engineering-only. Pull up the existing register, kill any row that nobody can defend within thirty seconds, and rewrite the surviving titles to be specific. Be ruthless. Most teams cut their row count by 40 to 60 percent in this session alone.
The second session is engineering plus one or two leadership stakeholders. Walk through the surviving rows, attach plain-language impact statements, assign single human owners, and add rough mitigation cost estimates for the top quarter of rows. By the end, you have the skeleton of a working register.
The first review meeting on the new cadence happens four weeks after that. By the third review, the register starts feeling like a real tool. Most of the inertia gets broken in those first three meetings.
The 137Foundry technology advisory practice has run this revival pattern with several mid-size engineering organizations. The pattern is almost identical regardless of the industry. The hard part is not the structure; it is the commitment to actually running the review meetings on the new cadence without skipping one for six months.
The integration that matters most
A risk register that lives in isolation will always drift back toward paperwork. The integration that matters most is connecting the register to the sprint planning ritual.
Once a sprint, the engineering lead opens the register, scans for any row that has been flagged as elevated impact in the previous month, and asks whether any of those rows should get a slot in the upcoming sprint. Most weeks, the answer is no. The point is not to add work; the point is to make sure the register is present in the decision.
When a row does get attention, the work that gets scheduled is real engineering work, not register maintenance. The register's purpose is to surface the right work. The work itself follows the normal sprint cadence.
For broader context on how a register connects to the rest of the technology governance stack, the longer 137Foundry guide on building a technology risk register your team will actually use walks through the full playbook including categories, cadence, and budget integration. The shorter version is: build it for the people who will make decisions, not for the auditor.
The lesson worth holding onto
A risk register is an artifact. A practice of using a risk register is a capability. Companies confuse the two all the time. They produce the artifact, check the compliance box, and assume they have built the capability. They have not.
The capability requires the meeting cadence, the named owners, the concrete titles, and the budget integration. The artifact without the practice is paperwork. The practice without the artifact is folklore. You need both, and you build them at the same time.
If your register has been dead for a while, the path back to a useful one is shorter than it feels. Two sessions and a recurring meeting will get you most of the way there. Engaging with a technology consulting firm 137Foundry on the cadence is one option for teams that want outside accountability on the practice. Doing it internally is also fine, as long as someone owns it.
A live register is one of the most undervalued tools in a technology organization. A dead one is one of the most common. The difference between the two is mostly about whether anyone is using it on a normal Tuesday.
Top comments (0)