Start with the risks that could stop your service from doing what you promise. A long spreadsheet is not the goal. You need to know what matters and who will do something about it.
A risk register is simply a record of those decisions. If every row says “high” and nothing changes, the document is not helping you choose where to spend time or money.
Replace the label with a specific problem
“Access risk” does not tell a manager much. Try this instead: “Former support staff may retain access to customer records because the support tool is missing from our departure checklist.”
Now there is something to investigate. Check who still has access. Remove access that is no longer authorized. Add the tool to the departure process and check that the revised process works.
That example is deliberately narrow. It shows why the issue matters without attaching every possible cyber threat to it.
Work out what deserves attention first
- What service or commitment could be affected?
- How serious would that effect be?
- How plausible is it in our actual setup?
- What protection is already working?
- What remains exposed despite that protection?
Use the same rating definitions across the team. A score can help sort the list, but explain the reason behind it. Two identical numbers may hide very different situations.
Do not count a planned purchase as protection that already exists. Keep today’s assessment separate from what you expect after the fix.
Turn the important rows into decisions
For each priority item, record the next action and its owner. Give the action a due date. State what would show that it worked.
If management decides to accept a remaining risk, record who had authority to decide and why. Include a review date or a change that would trigger another look. Writing “accepted” does not remove a contractual or legal obligation.
You can link to the work ticket instead of copying every detail into the register. The important part is that the decision and its follow-through remain easy to find.
Where SOC 2 fits
The AICPA criteria connect risk assessment with choosing how to respond. They also connect controls with reducing risks to acceptable levels. A template with hundreds of entries does not establish that those decisions happened.
Review the register with the people who run the service. Close actions only when the work has been checked. Revisit decisions when the service or its risks change.
Source
AICPA Trust Services Criteria: CC3.2 covers identifying and analyzing risks. CC3.4 addresses significant changes. CC5.1 connects control activities to risk reduction. The practical workflow above is guidance, not a prescribed AICPA worksheet.