AI Governance
ISO 42001, NIST AI RMF, DPDPA, and India's RBI/CERT-In regulatory frameworks. The emerging compliance layer on top of everything else — and the one clients are least prepared for.
ISO 42001 Deep Dive
Full AIMS implementation — Clause 6.1 walkthrough
ISO 42001 is an AI Management System standard — not just an AI risk framework. It requires documented processes, objectives, and continual improvement cycles. Clause 6.1 (AI Risk Assessment) is the technical core: you can't select controls from Annex A until you've run a structured risk assessment.
Clause 6.1 AI risk assessment
Walk through the full Clause 6.1 process for a real AI deployment. Returns a risk identification table, impact assessment with stakeholder harm categories, and control selection from Annex A.
Act as an ISO 42001 lead implementer. Walk me through implementing Clause 6.1 (AI risk assessment) for the following AI deployment. ORGANIZATION: [description — e.g., "financial services firm, 300 employees"] AI SYSTEMS: - System 1: [name, purpose, data inputs, output type, decision autonomy] - System 2: [repeat] Clause 6.1 requires: 1. Context establishment — who are the affected parties and what are their rights? 2. Risk identification — what can go wrong in the AI system's lifecycle? 3. Risk analysis — likelihood, severity, and reversibility 4. Risk evaluation — against organizational risk appetite 5. Risk treatment — control selection from ISO 42001 Annex A For each AI system: STEP 1 — Identification table: Risk | Category | Cause | Affected Parties | Potential Harm STEP 2 — Analysis matrix: Risk | Likelihood (1–5) | Severity (1–5) | Reversibility | Risk Score STEP 3 — Control selection: Risk | Risk Score | Selected Annex A Control | Control Description | Rationale After the assessment: Top 3 risks requiring immediate treatment. Which risks require external notification or disclosure?
Annex A control selection and rationale
ISO 42001 Annex A has 38 controls across 9 domains. This generates a targeted control selection for your specific AI systems — with the rationale that an auditor expects to see in the Statement of Applicability.
Generate an ISO 42001 Annex A control selection for the AI systems below. AI SYSTEMS AND RISKS: [paste from Clause 6.1 risk assessment — system descriptions and risk table] ORGANIZATIONAL CONTEXT: - Industry: [sector] - Regulatory requirements: [applicable regulations] - Risk appetite: [Low / Medium / High] For each Annex A domain (A.2 through A.10), determine applicable controls: Domain A.2 — Policies for AI: Which policy controls apply? Domain A.3 — Internal organization: Roles and responsibilities? Domain A.4 — Resources: AI competency and infrastructure? Domain A.5 — AI risk assessment processes: Assessment methods? Domain A.6 — AI system impact assessment: When and how? Domain A.7 — AI system lifecycle: Design, development, validation? Domain A.8 — Data for AI systems: Data governance? Domain A.9 — Information for interested parties: Transparency? Domain A.10 — Use of AI systems: Operational controls? For each selected control: | Control Ref | Control Name | Applicable | Justification | Implementation Status | Evidence Required | Controls marked Not Applicable need documented exclusion justification.
ISO 42001 certification auditors look for evidence of the PDCA cycle — Plan, Do, Check, Act. Documenting risks and selecting controls is just Plan and Do. The audit will specifically probe Check (how do you monitor AI system performance and risk over time?) and Act (what changes have you made based on monitoring findings?). Build the monitoring and review cadence into your implementation from day one, not as an afterthought before the audit.
NIST AI RMF
Enterprise AI governance maturity assessment and board reporting
NIST AI RMF at enterprise scale requires evidence requirements and board visibility — not just a maturity score. This lesson builds the scorecard with specific evidence expectations at each level and drafts the board-level AI governance report leadership actually reads.
NIST AI RMF scorecard with evidence requirements
The maturity level means nothing without the evidence that supports it. This generates the scorecard with specific evidence requirements at each level — so you know exactly what needs to exist before you can claim a given maturity.
Generate a NIST AI RMF governance maturity scorecard with evidence requirements for enterprise assessment. ORGANIZATION: [description — size, industry, AI systems in use] CURRENT STATE (describe each domain briefly): - Governance: [current state] - Understanding: [current state] - Accountability: [current state] - Risk Management: [current state] - Documentation: [current state] For each NIST AI RMF capability, provide: | Domain | Current Level (1–5) | Target Level | Evidence at Current Level | Evidence Gap | Evidence Required at Target Level | Level definitions: 1 = Ad hoc: No formal processes 2 = Defined: Documented but not consistently followed 3 = Managed: Consistently implemented, measured 4 = Quantified: Data-driven, metrics-based governance 5 = Optimizing: Continuous improvement, industry-leading Evidence at Target Level must be specific artifacts: "Board-approved AI policy signed by CEO," not "AI policy exists." After the scorecard: Which single action in each domain would most efficiently move to the next level?
Board-level AI governance report
Boards are increasingly required to have AI governance visibility — EU AI Act, SEC disclosure rules, and audit committee expectations are driving this. This drafts the quarterly board AI governance report in the format boards actually read.
Draft a board-level AI governance report for a quarterly board meeting. ORGANIZATION: [description] NIST AI RMF SCORECARD: [paste current maturity levels per capability] AI SYSTEMS IN OPERATION: [list with brief descriptions] KEY EVENTS THIS QUARTER: [any AI incidents, audits, new deployments, regulatory developments] UPCOMING AI INVESTMENTS: [planned AI initiatives] Draft a board report (1–2 pages equivalent) including: 1. AI Governance Executive Summary (3 sentences — current posture, key risks, status) 2. AI System Inventory Update (table: system, status, risk level change) 3. AI Governance Maturity Snapshot (NIST AI RMF scores — visual if possible as ASCII table) 4. Material Risks (2–3 risks requiring board awareness — business impact, not technical) 5. Regulatory Horizon (upcoming AI regulation affecting the organization in next 12 months) 6. Recommended Board Actions (1–2 decisions or approvals needed) Tone: Fiduciary. Risk-focused. No jargon. Executives should understand it in 5 minutes.
DPDPA & India Compliance
SaaS companies processing Indian user data
DPDPA 2023 is India's first comprehensive data protection law — and for SaaS companies with Indian users, compliance obligations are live even before all rules are notified. This lesson focuses on the operational implementation: rights mechanisms and privacy notices that work.
Data Principal rights implementation plan
DPDPA gives Data Principals five rights. Each requires a working mechanism — not a policy that says "users can contact us." This builds the implementation plan with timelines, system requirements, and the processes that satisfy each right.
Build a DPDPA 2023 Data Principal rights implementation plan. ORGANIZATION: [SaaS company description — size, Indian user count, data types processed] CURRENT SYSTEMS: [list relevant systems — user database, email platform, support tool, analytics] CURRENT RIGHTS MECHANISMS: [how users currently make requests, if at all] For each Data Principal right under DPDPA 2023, design an implementation: Right 1 — Access (Section 11): How can users see what data we hold? Right 2 — Correction and Erasure (Section 12): How can users correct or delete their data? Right 3 — Grievance Redressal (Section 13): How can users raise complaints? Right 4 — Nomination (Section 14): How can users nominate someone to act on their behalf? For each right: | Right | DPDPA Section | Current State | Required Mechanism | System Changes Needed | Timeline | Owner | After the plan: - Response timeframes required by law (DPDPA does not specify; best practice from GDPR: 30 days) - Which rights can be automated vs. require manual handling? - Privacy portal vs. email-based request handling — recommendation for org size?
Privacy notice and consent mechanism review
DPDPA Section 7 requires a layered consent notice that is specific, informative, and actionable. This reviews an existing privacy notice or drafts a DPDPA-compliant one from scratch.
Review and improve this privacy notice for DPDPA 2023 compliance, or generate a compliant notice from scratch. OPTION A — Review existing notice: CURRENT NOTICE: [paste existing privacy policy or notice text] OPTION B — Generate new notice: ORG: [description] DATA COLLECTED: [list all personal data types] PURPOSES: [list each processing purpose separately] THIRD PARTIES: [data processors and their roles] CROSS-BORDER TRANSFERS: [if any, to which countries] RETENTION: [per data type or category] Generate a DPDPA Section 7-compliant consent notice that: 1. Is layered (short notice for collection point + full notice link) 2. Uses plain language (not legalese) 3. Lists each purpose separately with a specific consent checkbox 4. Distinguishes required vs. optional data and purposes 5. Names the Grievance Officer or DPO and contact details 6. Explains how to withdraw consent and the consequences 7. States data retention periods per purpose Also: Short-form notice (< 100 words) for in-product collection points (signup form, checkout).
Significant Data Fiduciary designation brings additional obligations that most SaaS companies aren't ready for — mandatory Data Protection Impact Assessments, appointment of a Data Protection Officer, algorithmic accountability requirements, and periodic audits. The Data Protection Board will notify the thresholds. Companies processing large volumes of Indian user data, especially in sensitive categories (financial, health, children's data), should build SDF-ready controls now rather than scrambling after designation. The DPO appointment alone takes 2–3 months to execute properly.
RBI & CERT-In
Cybersecurity framework and incident reporting
RBI Cybersecurity Framework (2016) and CERT-In Directions (2022) are the two regulatory regimes that catch Indian fintech and financial services companies. The CERT-In Directions in particular have aggressive timelines and specific technical requirements that many organizations aren't tracking.
RBI CSF and CERT-In gap checklist
Feed in current security posture. Returns a combined gap checklist covering the RBI Cybersecurity Framework domains and the specific CERT-In Directions requirements — with timelines and action owners.
You are a GRC consultant. Assess a fintech's compliance with RBI Cybersecurity Framework (2016) and CERT-In Directions (2022). ORGANIZATION: [fintech/financial services description — size, services, customer count] CURRENT SECURITY POSTURE: - Incident response: [current process] - Log retention: [current retention period and systems] - VPN: [VPN usage and controls] - Network security: [firewalls, segmentation, monitoring] - Vulnerability management: [patch frequency, VA/PT schedule] - Vendor management: [third-party risk assessment process] - Audit history: [last cybersecurity audit date and finding status] Generate a gap checklist: RBI CSF REQUIREMENTS (key domains): | Requirement | RBI CSF Section | Current State | Gap | Action Required | Timeline | Owner | CERT-In DIRECTIONS (2022) — critical requirements: | Requirement | Direction | Current State | Gap | Action Required | Timeline | Owner | Key CERT-In requirements to cover: - Incident reporting: 6 hours from discovery - Log retention: 180 days (system logs, network logs, application logs) - NTP synchronization (Indian NTP servers) - VPN usage: user registration, log retention - Virtual asset transactions: logging requirements - Annual VAPT by CERT-In empanelled auditor
CERT-In incident response runbook
The 6-hour incident reporting requirement under CERT-In Directions is the hardest requirement to meet without a pre-built runbook. This generates the procedure for the first 6 hours after a cybersecurity incident — mapped to the CERT-In reporting format.
Generate a CERT-In incident response runbook for the 6-hour reporting window. ORGANIZATION: [fintech/financial services company description] SYSTEMS IN SCOPE: [key systems — application, database, network, cloud] INCIDENT RESPONSE TEAM: [roles — CISO, IR Lead, Legal, PR, Engineering] Generate a runbook covering the 0–6 hour window after a cybersecurity incident: HOUR 0–1 — Detection and Initial Triage: - Detection sources (SIEM alerts, user reports, vendor notifications) - Initial classification: Is this a CERT-In reportable incident? - Incident severity declaration (P1/P2/P3) - IR team activation procedure HOUR 1–3 — Containment and Evidence Preservation: - Immediate containment actions by system type - Evidence preservation checklist (logs, network captures, forensic images) - Stakeholder notification (internal) - Legal hold trigger criteria HOUR 3–6 — CERT-In Notification Preparation: - CERT-In reporting portal URL and submission steps - Required fields in CERT-In incident report form - What to include / exclude in the initial notification - Escalation to RBI if required (for regulated entities) HOUR 6+ — Post-notification: - Ongoing update cadence - Customer notification triggers - Documentation requirements for the post-incident report Include: CERT-In incident categories that trigger the 6-hour clock (ransomware, data breach, unauthorized access, website defacement, DDoS on critical infrastructure).
The 6-hour CERT-In reporting clock starts from the moment the organization becomes aware of the incident — not from when it's confirmed or when legal approves the report. Organizations that wait for full investigation before reporting will miss the deadline. File the initial notification with whatever is known at the 6-hour mark — the format explicitly accommodates incomplete information — and update it as investigation progresses. Failing to report on time is itself a regulatory violation, separate from the underlying incident.