From vaults, a file in the seed packEverything on this sheet is the source site's own text; the newsroom's chrome is outside it.
9. Risks to the business
| Risk | Why it matters | What to do |
|---|---|---|
| Executives refuse to accept | The method asks people to put their name and a date on what they carry. Many will not, at first. | Start with risks already visible at board level, where accountability is not in doubt. Make short intervals easy. Report "unaccepted" as a status the board sees, not as a failure of the person. |
| The GRC team sees a competitor | The service touches the register, and the register is theirs. | Integrate, write back into their platform, and make them the buyer. |
| It becomes a paperwork exercise | Acceptance without facts is a signature collection. | No risk without an "established by" fact; no acceptance without an interval; no interval without an action at expiry. |
| Evidence is sensitive | A risk vault holds a candid picture of weak controls. | Client-side encrypted vaults, keys held by the customer, read keys issued per audience. |
| Too granular to maintain | Fractal mapping can generate thousands of nodes. | Map fractally only where a risk is material. Most register rows stay as rows. |
| It depends on a few experts | The early work is judgement-heavy. | Write the method down as a playbook and train partners on it from the first year. |
| The tooling is partly unbuilt | risks.sgit.ai states plainly that essentially none of its model is implemented in code. The Risk Graph Explorer and the demo here are the working parts. | Sell the service, not the software. Build tooling only where the service repeats. |