Document control
Document ID: B-010
Author(s): GRC & Compliance Team
Version: 1.0
Date: 09-Nov-2026
Disclaimer:
This controlled document is intended for authorized SecureXcel use. It may not be reproduced, distributed, quoted, or disclosed outside its approved audience without prior authorization from the document owner.
| Document Title | AI Risk Criteria and Assessment Methodology Procedure | ||||
|---|---|---|---|---|---|
| Document Id | SecureXcel/AIMS/B-010 | Current Version | 1.0 | Date of Release | 09-Nov-2026 |
| Classification | Internal | Author | GRC & Compliance Team | ||
| Reviewed by | GRC & Compliance Lead | ||||
| Approved by | Management Representative | AI Governance Committee (AIGC) | |||
| Designation |
Revision History
| Version | Date | Author | GRC & Compliance Team | GRC & Compliance Lead | Management Representative |
|---|---|---|---|---|---|
| 1.0 | 25/09/2026 | GRC Lead | GRC Head | AIGC | Initial version |
1. Introduction
This procedure sets out the AI risk criteria and the methodology used to identify, analyse, evaluate and treat risks arising from SecureXcel’s AI systems. It implements ISO/IEC 42001:2023 clauses 6.1.1 (AI risk criteria), 6.1.2 (AI risk assessment), 6.1.3 (AI risk treatment), 8.2 and 8.3 (operational assessment and treatment), and supports the AI system impact assessment required by clause 6.1.4.
It supplements the Risk Management Policy and Procedure (A02), which governs information-security risk, and the AI Risk Management and Customer Relationship Procedure (B-008), which defines the overall risk cycle. Where this procedure and A02 differ on an AI risk, this procedure prevails.
2. Scope
AI Risk Criteria and Assessment Methodology Procedure
- All AI systems, models, AI-enabled features and externally supplied AI services formally included in the approved AIMS scope and AI System Inventory, together with any system added after a recorded scope decision.
- All lifecycle stages: requirements, design and development, verification and validation, deployment, operation and monitoring, change, and retirement.
- AI components supplied by third parties, including cloud services, external APIs and open-source models.
- Employees, contractors and suppliers who identify, assess, own or treat AI risks.
3. Roles, Responsibilities and Authorities
| Role | Responsibility and Authority |
|---|---|
| AI Governance Committee (AIGC) | Approves this procedure and any change to the risk criteria. Accepts residual risks rated High. Reviews risks scored Major or above on the individuals, groups and society dimension. |
| Top Management (CEO) | Informed of all Critical risks. Gives written approval in the rare case that a Critical residual risk is accepted. |
| AIMS Manager (GRC Head) | Accountable for maintaining the criteria and the AI risk register, for consistency with A02 and B-008, and for reporting risk status at management review. |
| GRC Lead | Coordinates assessments, facilitates workshops, maintains the register and its links to the impact assessment and the Statement of Applicability. |
| AI System Owner | Defines the context of the AI system, identifies and rates its risks, owns the treatment plans and reports progress. |
| Risk Owner | Named individual responsible for one risk, its controls and its treatment actions until closure. |
| Information Security & GRC Lead and Security Team | Provide security and privacy input to assessments and confirm the effectiveness of technical controls. |
| Legal & Compliance | Identifies legal and contractual requirements (TRAI, DoT, DPDPA and others) and advises on regulatory risk. |
| Internal Audit (GRC) | Verifies that assessments follow this procedure and reports findings through the internal audit programme. |
4. Relationship to Other Documents
| Document | How it relates |
|---|---|
| Risk Management Policy and Procedure (A02) | Parent policy for risk management. This procedure adds AI-specific criteria and aligns the risk levels to the 5–25 scoring scales. |
| AI Risk Management and Customer Relationship Procedure (B-008) | Defines the risk cycle and supplier and customer controls. Its risk criteria (section 3.1) are met by section 5 of this procedure. |
| AI System Impact Assessments Procedure (B-003) | The impact assessment result is the mandatory input for the consequence rating of individuals, groups and society. |
| AI Technology Risk Register | The register where risks are recorded. It uses the likelihood scale, impact scale and heat map adopted in section 5. |
| Statement of Applicability (SoA) | Records the Annex A controls selected to treat AI risks and the justification for each. |
| AI Model Monitoring and Improvement Policy (AI-005) | Supplies the monitoring metrics, thresholds and alert levels that feed risk likelihood and key risk indicators. |
5. AI Risk Criteria
5.1 Likelihood Scale
Likelihood is scored from 5 to 25. The scale is the same as in the AI Technology Risk Register (Annexure 1).
| Score | Rating | Occurrence in the future | Occurrence in the past |
|---|---|---|---|
| 25 | Almost Certain | Routine feature every month within the next year | Similar events commonly occurred every month |
| 20 | Likely | May arise several times within the next year | Similar events occurred several times in the past year |
| 15 | Possible | May arise once or twice within the next year | One or two similar events in the past year |
| 10 | Unlikely | May occur once or twice between year 2 and year 5 | Similar events in the last 2 to 5 years, not routinely |
| 5 | Rare | Almost impossible between year 2 and year 5 | Similar events have never occurred |
5.2 Impact Scale
Impact is scored from 5 to 25 in each dimension. The impact score of a risk is the highest score across all dimensions. The organisational dimensions follow Annexure 2 of the register; the last column is added by this procedure to meet clause 6.1.2 d) 1), which requires the consequences for individuals, groups and society to be assessed.
| Score | Rating | Organisation (financial, per register) | Individuals, groups and society (SecureXcel AI Services) |
|---|---|---|---|
| 25 | Catastrophic | 30% or more of capital or investments, or PBT reduced by over 5% | Protection fails, or legitimate traffic is blocked, at national scale; regulator or licence action |
| 20 | Major | 20–30% of capital or investments, or PBT reduced by 3.5–5% | Systematic false blocking of a sender category, or fraud reaching consumers at scale; mandatory regulator notification |
| 15 | Moderate | 10–20% of capital or investments, or PBT reduced by 2–3.5% | Repeated false positives for a sender group, or personal data of a limited number of people exposed without harm |
| 10 | Minor | 5–10% of capital or investments, or PBT reduced by 0.5–2% | Isolated false positives or negatives corrected within the service level |
| 5 | Insignificant | Under 5% of capital or investments, or PBT reduced by under 0.5% | No identifiable person or group affected |
Reputation, stakeholder, operational and strategic criteria in Annexure 2 of the register apply unchanged.
5.3 Risk Rating and Levels
Inherent and residual risk are calculated as Likelihood × Impact. The level is taken from the table below. A score of exactly 75 is Low; the register leaves this value unassigned and this procedure closes the gap.
| Level | Score | Required action |
|---|---|---|
| Critical | Over 260 | Immediate action. Monthly progress reports to management. |
| High | 151 to 260 | Senior management attention. Treatment plan with owner and date. |
| Moderate | 76 to 150 | Functional head attention. Periodic monitoring. |
| Low | 75 or less | Manage by routine procedures. |
5.4 Risk Acceptance Criteria
| Residual level | Who may accept | Conditions |
|---|---|---|
| Low | Risk owner | Recorded in the register. Reviewed annually. |
| Moderate | AI System Owner with the functional head | Justification recorded. Reviewed at least quarterly. |
| High | AIGC | Minuted decision, treatment plan with owner and target date, reviewed at every management review. |
| Critical | Not accepted | Treated immediately. Acceptance only for a critical business requirement, with written approval of the CEO and AIGC, a compensating control and a review within 6 months. |
A risk scored Major or above on the individuals, groups and society dimension is reviewed by the AIGC whatever its residual level.
6. AI Risk Assessment Procedure
6.1 Assessment Steps
| # | Step | Activity | Output |
|---|---|---|---|
| 1 | Establish context | AI System Owner records purpose, users, jurisdictions, data, model types, suppliers and the current impact assessment. | System context record |
| 2 | Identify risks | Workshop using the risk sources in B-008 Appendix B (fairness, robustness, safety, security, transparency, privacy, environment), impact assessment findings, monitoring indicators, incidents, supplier information and legal requirements. | List of risks with IDs |
| 3 | Rate consequence | Score every dimension in section 5.2. Take the severity for individuals, groups and society from the impact assessment. The highest score is the impact. | Impact score |
| 4 | Rate likelihood | Score using section 5.1 with evidence: incidents, monitoring data, test results. | Likelihood score |
| 5 | Calculate inherent risk | Likelihood × Impact. Read the level from section 5.3. | Inherent score and level |
| 6 | Assess controls | List existing controls. Rate their effectiveness using Annexure 7 of the register. Re-score likelihood and impact to give the residual risk. | Residual score and level |
| 7 | Evaluate | Compare the residual level with the acceptance criteria in section 5.4 and prioritise risks for treatment. | Prioritised list |
| 8 | Record | Enter the risk in the AI Technology Risk Register with its impact assessment finding and SoA control links. | Updated register |
6.2 Frequency and Triggers
Every AI system is assessed:
- Before deployment or purchase, together with the impact assessment.
- Before any material change: new model version, new data source, new customer segment or new jurisdiction.
- After an AI incident, or any Level 3 or Level 4 monitoring alert under AI-005.
- When an impact assessment identifies a new consequence. The register is updated within 7 days.
- At least annually, aligned with the impact assessment review, and quarterly for risks rated High or Critical.
7. AI Risk Treatment and Residual Risk
Risks that do not meet the acceptance criteria are treated as follows:
- Select a treatment option: modify the risk with controls, retain it, avoid it by stopping the activity, or share it with a supplier or customer through a contract (B-008 section 3.3.1).
- Determine the controls needed and compare them with ISO/IEC 42001:2023 Annex A to confirm that no necessary control is omitted. Add controls beyond Annex A where required.
- Record each treatment in a plan with the objective, actions, owner, resources, target date, key risk indicators with comfortable, warning and critical thresholds, and the expected residual level.
- Update the Statement of Applicability when a control is added or its status changes.
- Obtain approval of the treatment plan and of the residual risk from the authority in section 5.4 before implementation. Keep the approval as a record.
8. Monitoring, Reporting and Review
- Risk owners update key risk indicators at the frequency set in the register. The GRC Lead compiles a monthly report to the AIGC.
- The AIGC reviews all High and Critical risks quarterly.
- Risk status, changes to the risk profile and treatment progress are inputs to every management review under clause 9.3.
- Internal audit checks that assessments follow this procedure and that treatment actions close on time.
- This procedure is reviewed at least annually and after any AI incident that shows the criteria were inadequate.
9. Records and Documented Information
| Record | Owner | Retention |
|---|---|---|
| AI Technology Risk Register and change history | AIMS Manager | Minimum 3 years |
| Risk assessment record (Appendix B) | AI System Owner | Minimum 3 years |
| Treatment plans and approvals | Risk Owner | Minimum 3 years |
| AIGC decisions on risk acceptance | GRC Lead | Minimum 3 years |
| Management review inputs on risk | GRC Lead | Minimum 3 years |
Where the AI Data Protection and Retention Policy (AI-002) sets a longer period, that period applies.
10. Compliance with ISO 42001:2023 and Other Standards
| Requirement | Where met | Clause |
|---|---|---|
| AI risk criteria including acceptance criteria | Section 5 | 6.1.1 |
| Consistent, valid and comparable assessment | Sections 5 and 6 | 6.1.2 a), b) |
| Risk sources and consequences for individuals and society | Sections 5.2 and 6.1 | 6.1.2 c), d) 1) |
| Likelihood, level and prioritisation | Sections 5.3 and 6.1 | 6.1.2 d) 2), 3), e) |
| Treatment options, controls, SoA and approval | Section 7 | 6.1.3 |
| Planned intervals and change triggers | Section 6.2 | 8.2, 8.3 |
| Documented information retained | Section 9 | 6.1.2, 7.5 |
| Information security risk management | Risk Management Policy and Procedure (A02) | ISO/IEC 27001:2022 6.1.2 |
Appendix A: Proposed Additions to the AI Risk Register (SecureXcel AI Services)
The 15 risks in the AI Technology Risk Register (KR-AI-T-01 to 15) are technology risks. The risks below are proposed for a new KR-AI-E series. Scores are proposals for the risk owners to confirm; residual scores are set after control effectiveness is reviewed.
| ID | Risk | Inherent (L × I) | Suggested owner |
|---|---|---|---|
| KR-AI-E-01 | Legitimate senders over-blocked, causing unfair outcomes for a sender group | 15 × 15 = 225 High | AI System Owner |
| KR-AI-E-02 | Fraud and phishing messages reach consumers at scale after evasion or drift | 15 × 20 = 300 Critical | AI System Owner |
| KR-AI-E-03 | Personal data in message content exposed or processed outside its lawful basis | 10 × 20 = 200 High | Information Security & GRC Lead / Legal |
| KR-AI-E-04 | Data poisoning, model inversion or exfiltration | 20 × 15 = 300 Critical | Information Security & GRC Lead |
| KR-AI-E-05 | Third-party components fail or misbehave, including APIs and open-source model licences | 15 × 15 = 225 High | Procurement / AI System Owner |
| KR-AI-E-06 | Regulatory change (TRAI, DoT, DPDPA Rules, EU AI Act) makes a control or claim non-compliant | 15 × 15 = 225 High | Legal & Compliance |
| KR-AI-E-07 | Use beyond intended purpose, such as political filtering or surveillance | 10 × 20 = 200 High | AIGC |
| KR-AI-E-08 | Human oversight fails through review-queue backlog or analyst error | 15 × 10 = 150 Moderate | AI System Owner |
| KR-AI-E-09 | Training labels or data provenance unreliable, hiding bias | 15 × 15 = 225 High | Data Engineering Lead |
| KR-AI-E-10 | Retention and deletion conflict or fail (DoT retention against DPDPA erasure) | 10 × 15 = 150 Moderate | Data Governance |
| KR-AI-E-11 | Staff lack AI awareness or role-specific competence | 15 × 10 = 150 Moderate | HR |
| KR-AI-E-12 | Compute and energy use of AI workloads exceeds targets | 15 × 5 = 75 Low | IT |
Appendix B: AI Risk Assessment Record
Each assessment is documented using these fields, held in the AI Technology Risk Register or in a linked record.
| Field | Content |
|---|---|
| Risk ID and title | Unique ID and a short heading |
| AI system and lifecycle stage | System ID from the AI system inventory and the stage affected |
| Risk source | Source from B-008 Appendix B or a supplier, legal or incident source |
| Risk event and description | What could happen and why |
| Impact assessment link | Finding ID in the current impact assessment and the consequence for individuals, groups and society |
| Likelihood and impact | Scores with the evidence used, per sections 5.1 and 5.2 |
| Inherent risk | Score and level |
| Existing controls | Controls in place, their effectiveness rating and evidence |
| Residual risk | Score and level after controls |
| SoA control reference | Annex A control or controls that treat the risk |
| Treatment plan | Option, actions, owner, resources, target date, key risk indicators |
| Acceptance | Approving authority, decision and date |
| Review date | Next scheduled review and last review outcome |