A board AI risk assessment is not a policy document. It is five decisions with a named owner, a defined evidence requirement, an escalation trigger and a review cadence for each. Below is the template, and the exception process that keeps it from going stale the week after the board signs it off.
Most AI risk assessments read like a policy: principles, a list of risks, a statement of intent. That satisfies an audit checklist once. It does not tell anyone who approves the next AI use case, what evidence they need before they approve it, or what happens when a team wants an exception. A board that cannot answer those three questions does not have an AI risk assessment, it has a memo.
What decisions does the board actually need to make?
Five decisions come up in any AI governance programme, whatever the industry. Each needs an owner who is a named role, not a committee; evidence that owner must see before deciding; a trigger that forces the decision up to the next level; and a cadence for revisiting it, because AI systems and their risk profile change faster than annual review cycles assume.
| Decision | Owner | Evidence required | Escalation trigger | Review cadence |
|---|---|---|---|---|
| Approve an AI use case for production | CISO or Head of AI Governance | Risk assessment, data classification, model or system card | Use case touches regulated, customer or safety-critical data | Before go-live, then quarterly |
| Approve an AI agent to act without human sign-off | Risk Committee | Logged test runs, rollback plan, blast-radius analysis | Action is irreversible or affects a third party directly | Per deployment, then on any material change |
| Approve a third-party AI model or vendor | Procurement lead with CISO sign-off | Security assessment, data processing terms, incident history | Vendor fails the security review or handles regulated data | Annually, or on contract renewal |
| Grant an exception to AI policy | Business unit owner with CISO co-sign | Written justification, compensating control, time-box | Exception exceeds its agreed time-box or is requested a second time | At exception request, then at expiry |
| Escalate an AI-related incident | Board Risk Committee | Incident timeline, affected systems, regulatory exposure | Incident meets a regulatory reporting threshold or affects customer data | Immediate, then a post-incident review |
If your current AI risk assessment cannot produce this table with names in the owner column, it has not been put into practice yet, whatever the document says.
How does the exception process work?
The fifth row is the one boards usually skip, and it is the one that decides whether the other four hold up. AI use cases move faster than quarterly review cycles. A team will ask for an exception: to skip a control ahead of a deadline, to use a model that has not cleared vendor review, to let an agent take an action the policy currently blocks.
An exception process needs three things to be more than a rubber stamp:
- A written justification and a compensating control. Not "we need this by Friday." What risk is being accepted, and what is in place to catch it if it goes wrong.
- A time-box. Every exception expires by default. It does not become the new policy by inertia.
- A log that survives the exception. When the exception expires or is escalated, whoever reviews it needs to see what was approved, by whom, and against what evidence, not a reconstruction from memory or email.
That last point is where most exception processes fail: the exception is granted verbally or in a chat thread, and by the time a regulator or an internal auditor asks about it, the evidence trail is gone. The decision-rights table above only works if every decision in it, including exceptions, produces a durable record.
How does this map to NIS2, DORA, the EU AI Act and ISO 27001?
These four frameworks do not converge on identical requirements, and which ones apply to your organisation depends on sector, size and the specific AI systems in scope. They all share a demand for the same three things: a documented risk management process, named accountability, and an evidence trail that a third party can inspect after the fact.
| Framework | What it generally requires | Where a board AI risk assessment connects |
|---|---|---|
| NIS2 | Risk management measures for essential and important entities, with management-body approval and oversight of those measures, plus incident reporting on defined timescales | The decision-rights table gives the named ownership and review cadence NIS2 expects at board level |
| DORA | An ICT risk management framework approved by the management body, a register of ICT third-party arrangements, and incident classification and reporting | The vendor-approval and incident-escalation rows map directly to DORA's ICT third-party and incident provisions |
| EU AI Act | Risk-based obligations that scale with system classification, including a risk management system, human oversight and logging for higher-risk AI systems | The agent-autonomy and exception rows are where human oversight and logging obligations bite hardest |
| ISO 27001 | A certified information security management system: risk assessment methodology, documented controls, internal audit and management review | The evidence-required column gives auditors what an ISMS review expects to see per decision, not just per control |
Treat this table as a starting point for your own legal and compliance review, not as a substitute for it. Applicability, exact thresholds and reporting timescales vary by entity classification and jurisdiction.
Where does SenseOn fit, and where doesn't it?
SenseOn is not a GRC platform. It does not run your exception workflow, and it does not manage your AI policy. Those stay with the board, the risk committee and whoever in the business owns the decisions in the table above.
What SenseOn provides is the evidence layer underneath those decisions. Every AI and analyst action, including AI agent governance decisions, writes to the append-only, immutable Decision Trace: a structural guarantee of coverage, not a sampling rate. That gives chain-of-custody support for the kind of audit trail NIS2, DORA, the EU AI Act and ISO 27001 all ask for in some form. Support is not the same as compliance. Compliance against any of these frameworks is your organisation's determination to make, informed by your legal function, not a status SenseOn or any vendor can confer.
On the platform's own security posture: SenseOn is ISO 27001 certified via BSI, with the certificate available at trust.senseon.io, and holds Cyber Essentials Plus, a UK government procurement gate. Certification is worth having and worth checking on a vendor. A certificate tells you a point-in-time audit passed; it does not tell you whether the exception process in row four of your own table is still being followed six months later. That verification stays with your board and your internal audit function.
Related reading
This article is the AI-specific layer on top of governance work most boards already have underway:
- Reporting security to the board: the wider board-reporting practice this assessment feeds into
- NIS2 compliance guide: the full NIS2 requirement set beyond the AI-specific slice above
- DORA compliance guide: ICT risk management and third-party requirements in detail
- ISO 27001 controls guide: the ISMS controls behind the certification referenced above
For the wider AI accountability picture, see The CISO's AI Accountability Playbook.
