# 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. |