Framework Playbooks
Eight frameworks, one prompt each. ISO 27001, SOC 2, CMMC L2, FedRAMP, HIPAA, ISO 42001, NIST CSF 2.0, and DPDPA — the workflows practitioners actually run, not framework overviews.
ISO 27001:2022
Risk register and SoA from a first pass
ISO 27001:2022 starts and ends with risk. Clause 6.1.2 requires a formal risk assessment before you can select controls — and the risk register is the artifact assessors pull first. Build it right, and everything downstream (SoA, treatment plan, audit evidence) falls into place.
Generate the risk register
Feed in org type and key assets. Returns a structured risk register with Annex A control references you can bring into a client workshop or review session immediately.
You are an ISO 27001:2022 lead implementer. Generate a risk register for the following organization. ORG: [e.g., "SaaS company, 50 employees, processes customer PII and financial data, hosted on AWS"] For each risk, provide: | Asset | Threat | Vulnerability | Likelihood (1–5) | Impact (1–5) | Risk Score | Risk Level | Annex A Control Ref | Treatment | Include at least 15 risks covering: - Information assets (data, systems, IP) - Physical and environmental - Human (insider, social engineering) - Third-party and supply chain - Operational continuity Treatment options: Accept | Mitigate | Transfer | Avoid Risk Level: Critical (20–25) | High (15–19) | Medium (8–14) | Low (1–7) Sort by Risk Score descending.
Build the Statement of Applicability
The SoA documents which Annex A controls apply, which are excluded, and why. Auditors scrutinize this closely — vague justifications fail. This generates defensible language for every line.
Generate a Statement of Applicability (SoA) for an ISO 27001:2022 certification. ORG CONTEXT: [org type, size, key risks from risk register] EXCLUDED CONTROLS (if any): [list any Annex A controls that don't apply and why] For each Annex A control (A.5 through A.8), provide: | Control Ref | Control Name | Applicable? | Justification | Implementation Status | Evidence Reference | Justification must be specific — not "not applicable to our org" but "not applicable because [specific business, legal, or contractual reason]." Implementation Status: Implemented | Partially Implemented | Planned | Not Implemented Flag any controls where exclusion creates residual risk that should be flagged to top management.
Risk appetite must be defined before scoring — otherwise a "4×4 = 16 High" in one risk register might be a "Medium" in another with different thresholds, and auditors will call it out. Get explicit sign-off from leadership on the scoring matrix before running the register in a client workshop.
SOC 2 Type I & II
CC6 logical access gap analysis
SOC 2 audits live or die on the CC6 (Logical and Physical Access) family. It's where most findings cluster because it touches identity, access reviews, privileged accounts, and authentication — all the hard things organizations delay. This workflow gets you to a CC6 gap analysis fast.
CC6 gap analysis
Paste your current logical access controls. Returns a criterion-by-criterion gap table with the evidence population you'll need and sample test procedures an auditor would run.
I am performing a SOC 2 Type II readiness assessment. Analyze our current logical access controls against CC6. OUR CONTROLS: [describe or paste your current access controls — e.g., "We use Okta for SSO, require MFA for all users, conduct quarterly access reviews via Workday export, privileged accounts require manager approval in Jira"] For CC6.1 through CC6.8, provide: | Criterion | Criterion Description | Current Control | Status (Met/Gap/Partial) | Evidence Needed | Sample Auditor Test Procedure | Evidence needed should be specific artifacts: "Quarterly access review sign-off with timestamp, exported from Okta, reviewed by CISO." After the table: - Top 3 CC6 gaps most likely to generate findings - Evidence collection timeline (what takes longest to produce) - Common auditor questions for CC6 interviews
Build the evidence population list
The auditor will request a specific evidence population. This maps every CC6 criterion to the exact artifacts they'll want — so you're pulling the right files on day one of fieldwork.
Generate an evidence population list for a SOC 2 Type II audit covering the CC6 criteria. AUDIT PERIOD: [e.g., "January 1 – December 31, 2024"] SYSTEMS IN SCOPE: [list key systems — IdP, endpoint, cloud, ticketing] For each CC6 criterion, list: | Criterion | Evidence Item | Source System | Frequency | Format | Owner | Evidence item examples: "Access provisioning tickets," "Quarterly user access review logs," "MFA enrollment report," "Privileged account list with approval records" Group by: Always-on evidence (logs, configs) | Periodic evidence (reviews, reports) | Point-in-time evidence (screenshots, exports) Flag any criterion where evidence collection requires > 2 business days — these are scheduling risks during fieldwork.
The System Description is where SOC 2 failures start — not the controls. If the description says "we use MFA for all systems" and the auditor finds one system without it, that's a qualified opinion. Audit the System Description against actual system inventory before fieldwork begins. Every claim in that document needs to be testable.
CMMC L2 Families
AC, IA, AU domain-specific deep dives
CMMC L2 assessment goes to the AO level — 320 assessment objectives across 14 families. The AC, IA, and AU families generate the most findings for most clients. This workflow builds the interview question bank and assessment plan for any CMMC family in under 5 minutes.
Build the family-level assessment plan
Feed any CMMC practice ID and get back the CCA-standard assessment plan: what to examine, who to interview, what to test. This is what a lead CCA runs through during fieldwork.
You are a CCA assessor. For the specified CMMC L2 practice, generate a complete assessment plan. PRACTICE: [e.g., "AC.L2-3.1.1 — Limit system access to authorized users"] FRAMEWORK: CMMC L2 (NIST 800-171A) Provide: 1. Assessment Objective text (from NIST 800-171A) 2. EXAMINE items: Documents, policies, and configurations to review 3. INTERVIEW subjects: Roles to interview and specific questions per role 4. TEST procedures: Technical tests and sampling approach 5. Example findings language: - MET: "[Practice] is Met. Evidence: [specific artifacts reviewed]" - NOT MET: "[Practice] is Not Met. [specific gap observed]. Impact: [risk description]" 6. Common compensating control claims for this practice — and whether they're valid Repeat for all AOs within this practice (may be multiple per practice).
Generate the interview question bank
Pull a targeted interview question list for any CMMC control family. These are the questions an actual CCA asks — organized by role so you can assign them to the right interview sessions.
Generate a CMMC L2 interview question bank for the specified control family. CONTROL FAMILY: [e.g., "IA — Identification and Authentication"] INTERVIEW ROLES: [e.g., "IT Administrator, ISSO, Help Desk Lead, End Users (sample)"] For each role, provide 8–12 targeted interview questions that: - Are specific to CMMC L2 AOs in this family - Cannot be answered with a simple "yes" — require demonstrated knowledge - Follow the NIST 800-171A examine/interview/test methodology - Are phrased as an assessor would ask them (neutral, not leading) Format: Role: [role name] Questions: 1. [Question] — AO it maps to: [AO ID] ... After each role's questions: "Red flag answers" — what to note if the interviewee says X.
Know the POA&M cutoff before scoring. Under CMMC conditional certification rules, only specific practices can be on a POA&M — and the list is narrower than most practitioners think. AC.L2-3.1.20 (CUI on external systems) and any practice touching MFA, for example, typically cannot be deferred. Get current DoD guidance on eligible practices before advising a client on their POA&M strategy.
FedRAMP Moderate
SAP-to-SAR workflow using AI
FedRAMP assessment runs from SAP to SAR. Every control family needs a scoped assessment plan section before fieldwork begins — methods, test cases, sampling rationale, timeline. This workflow drafts that section in one pass.
Draft the SAP control family section
Feed the control family. Returns a FedRAMP-structured SAP section with assessment methods, test cases per control, and sampling logic — ready to drop into the SAP document for PMO review.
Draft a FedRAMP Moderate Security Assessment Plan section for a control family. CONTROL FAMILY: [e.g., "IA — Identification and Authentication"] SYSTEM: [brief system description — e.g., "Cloud-hosted SaaS platform, AWS GovCloud, 500 federal users"] ASSESSMENT BOUNDARY: [what's in scope — e.g., "SaaS application layer, AWS infrastructure, Okta IdP"] Generate the SAP section including: 1. Assessment boundary for this family (what's included/excluded) 2. Assessment methods: Examine / Interview / Test for each control 3. Test cases per control (specific procedures, not generic) 4. Sampling rationale (for interview subjects and system components) 5. Timeline estimate (days of fieldwork for this family) 6. Special considerations (e.g., inherited controls from FedRAMP-authorized IaaS) Format following FedRAMP SAP template structure. Flag any controls where agency ATO vs JAB authorization changes the assessment approach.
Write the SAR finding
When a test fails, the finding writeup is where 3PAOs lose time. This generates the SAR entry with the correct risk rating, required fields, and recommendation language.
Write a FedRAMP SAR finding for a failed control test. CONTROL: [control ID and name — e.g., "IA-5(1) — Authenticator Management | Password-Based Authentication"] WHAT WAS TESTED: [describe the test procedure run] WHAT WAS OBSERVED: [what the assessor found — e.g., "Minimum password length is set to 8 characters, below the FedRAMP Moderate mandatory parameter of 12"] MANDATORY PARAMETER (if applicable): [the FedRAMP PMO-specified requirement] Generate the SAR finding entry: - Finding ID: [your numbering] - Control: [ID] - Finding Title: [action-oriented, < 10 words] - Severity: [Critical / High / Moderate / Low — per FedRAMP risk rating methodology] - Finding Description: [what was observed, technically specific] - Risk Narrative: [business/mission impact if unaddressed] - Recommendation: [specific remediation action, not generic] - Operational Requirement?: [Yes/No — if Yes, explain the OR rationale]
Inherited vs. customer-responsible controls trip up every new FedRAMP assessor. If the CSP uses an authorized IaaS (AWS GovCloud, Azure Government), a significant portion of lower-level controls are inherited — and you don't test them, you document the inheritance and verify the authorization status. Always pull the CRM (Customer Responsibility Matrix) from the IaaS provider before scoping assessment work. Testing inherited controls wastes fieldwork days.
HIPAA Security Rule
Administrative safeguards gap assessment
HIPAA Security Rule assessment starts with §164.308 — Administrative Safeguards. This is where most organizations have the biggest gaps because the requirements are process-heavy, not technical. One prompt covers the whole safeguard section.
§164.308 administrative safeguards gap table
Feed your current administrative controls. Returns a specification-by-specification gap table with status, recommended controls, and draft policy language for each gap. Both required and addressable specifications covered.
Assess our HIPAA Administrative Safeguards compliance under §164.308. OUR CURRENT CONTROLS: [describe existing policies and procedures — e.g., "We have a security incident response policy, conduct annual HIPAA training, and perform workforce screenings. We don't have a formal risk analysis documented for this year."] For each §164.308 implementation specification, provide: | Specification | Type (Required/Addressable) | Status | Gap | Recommended Control | Sample Policy Language | Specifications to cover: - §164.308(a)(1): Security Management Process [Required] - §164.308(a)(1)(ii)(A): Risk Analysis [Required] - §164.308(a)(1)(ii)(B): Risk Management [Required] - §164.308(a)(1)(ii)(C): Sanction Policy [Required] - §164.308(a)(1)(ii)(D): Information System Activity Review [Required] - §164.308(a)(2): Assigned Security Responsibility [Required] - §164.308(a)(3): Workforce Security [Addressable specs] - §164.308(a)(4): Information Access Management [Addressable specs] - §164.308(a)(5): Security Awareness and Training [Addressable specs] - §164.308(a)(6): Security Incident Procedures [Required] - §164.308(a)(7): Contingency Plan [Addressable specs] - §164.308(a)(8): Evaluation [Required]
Generate the risk analysis narrative
§164.308(a)(1)(ii)(A) requires a documented risk analysis. This is the most scrutinized document in a HIPAA audit and the most commonly missing one. This generates the narrative structure you can populate with client-specific data.
Draft a HIPAA Risk Analysis narrative structure for §164.308(a)(1)(ii)(A). ORG: [healthcare entity type — e.g., "multi-location dental practice, 8 providers, uses EHR via Epic"] ePHI SYSTEMS: [list systems that create, receive, maintain, or transmit ePHI] CURRENT THREATS IDENTIFIED: [any known threats or vulnerabilities] Generate a risk analysis document framework: 1. Scope Statement — what ePHI and systems are covered 2. Threat Identification — table of realistic threats (at minimum 10) by category 3. Vulnerability Assessment — corresponding vulnerabilities 4. Likelihood and Impact Matrix — with ratings and rationale 5. Risk Level Determination — prioritized risk list 6. Existing Controls — current mitigations mapped to risks 7. Residual Risk — what remains after controls 8. Risk Management Summary — recommended actions Format as a formal document. Include the analysis date and review frequency statement required for §164.308(a)(8).
Addressable does not mean optional — this is the most common client misconception in HIPAA work. Addressable specifications must be implemented if reasonable and appropriate, OR the organization must document why an equivalent alternative satisfies the standard. If they decide not to implement an addressable spec, that decision needs to be documented in writing with a risk justification. "We decided not to" without documentation is a finding.
ISO 42001 (AI Management)
AI system inventory and impact assessment
ISO 42001 is the first international standard for AI Management Systems. It follows the Annex SL structure (same as ISO 27001 and ISO 9001), so the documentation framework is familiar — but the content is new. Start with an AI system inventory and impact assessment.
Build the AI system inventory
Before any risk assessment, you need to know what AI systems exist and what they do. The boundary between "AI system" and "software with ML features" under ISO 42001 is deliberately broad — capture everything.
You are an ISO 42001 lead implementer. Build an AI system inventory for the following organization. ORG: [description — e.g., "fintech startup, uses GPT-4 for customer support chat, in-house ML model for transaction fraud detection, and a vendor tool for credit scoring"] KNOWN AI TOOLS AND SYSTEMS: [list all AI/ML systems, including vendor tools] For each AI system, provide: | System Name | Type (GenAI / ML / Automated Decision) | Purpose | Data Inputs | Output Type | Decision Autonomy | Vendor or In-house | Affected Persons | Risk Level (ISO 42001 Annex C) | Decision Autonomy: Human-in-the-loop | Human-on-the-loop | Fully Automated Risk Level (from ISO 42001 Annex C): Minimal | Limited | High | Unacceptable After the inventory: - Systems requiring a dedicated AI Impact Assessment (Clause 6.1.2) - Systems where current data handling needs review - Vendor AI tools where you need transparency documentation
AI risk register (ISO 42001 format)
The AI risk register maps each system to ISO 42001 Annex A controls. Unlike general IT risk, AI risks include bias, explainability gaps, data drift, and model manipulation — this prompt covers all of them.
Generate an AI risk register in ISO 42001 format for the systems in the inventory below. AI SYSTEM INVENTORY: [paste inventory from previous prompt] For each AI system, identify risks across these categories: - Data risks (training data bias, data quality, privacy of data subjects) - Model risks (accuracy drift, adversarial attacks, explainability) - Operational risks (human oversight failures, automation bias) - Third-party risks (vendor model changes, API dependency) For each risk: | System | Risk Category | Risk Description | Likelihood | Impact | Risk Score | ISO 42001 Annex A Control | Treatment | Owner | Then: Top 5 risks by score. Which risks require disclosure to affected persons under applicable regulation (GDPR Art. 22, DPDPA, etc.)?
Defining what counts as an "AI system" is the first argument you'll have with clients. Under ISO 42001, AI systems include ML models, neural networks, and rule-based systems that exhibit adaptive behavior — but a simple decision tree with static thresholds typically falls outside scope. The key question is whether the system can generate outputs that influence decisions affecting people. When in doubt, include it in the inventory and note the boundary decision in writing.
NIST CSF 2.0
5-domain cybersecurity governance maturity scorecard
NIST CSF 2.0 (Governance, Cybersecurity, Accountability, and Risk Management Framework) Documentation) is a 5-domain maturity framework for AI governance. It's assessor-agnostic and works alongside ISO 42001 or as a standalone readiness check. The output is a scored maturity card plus an improvement roadmap.
NIST CSF 2.0 maturity scorecard
Feed in current AI governance state across the 5 domains. Returns a maturity scorecard with level (1–5) per domain, specific gaps, and the evidence an assessor would expect to see at each level.
Using the NIST CSF 2.0 framework, assess our cybersecurity governance posture across 5 functions. ORG: [description and AI system types] CURRENT STATE: - Governance: [e.g., "No formal AI policy. CISO owns ad-hoc AI review."] - Understanding: [e.g., "Engineers trained on prompt engineering. No formal AI literacy program for business users."] - Accountability: [e.g., "No designated AI Responsible Officer. Vendor agreements reviewed by legal."] - Risk Management: [e.g., "No AI-specific risk register. General IT risk process applied."] - Documentation: [e.g., "System descriptions exist in Confluence. No AI-specific model cards or impact assessments."] For each domain, provide: | Domain | Current Maturity (1–5) | Key Gaps | Priority Actions | Evidence Required at Target Level | Maturity levels: 1=Ad hoc | 2=Defined | 3=Managed | 4=Quantified | 5=Optimizing Then: Overall NIST CSF 2.0 score. Which function to prioritize for fastest maturity improvement?
NIST CSF 2.0 improvement roadmap
From the scorecard, build a 90-day improvement roadmap that moves each domain one maturity level up. Practical, prioritized, with owner assignments.
Build a 90-day cybersecurity governance improvement roadmap based on this NIST CSF 2.0 maturity assessment. NIST CSF 2.0 SCORECARD: [paste your maturity scorecard output] TARGET: Move each domain up by at least 1 maturity level within 90 days. Generate a sprint plan: - 30-day sprint: Quick governance wins (policy stubs, ownership assignments, basic documentation) - 60-day sprint: Process implementations (risk register, training, vendor review) - 90-day sprint: Audit-readiness (evidence packages, governance committee, ongoing monitoring) For each action: | Action | Domain | Owner (role) | Effort | Deliverable | Maturity gain | End with: What a board-level AI governance report looks like at target maturity. Draft a 5-bullet executive summary for current state.
DPDPA (India)
Data Principal rights and consent management
India's Digital Personal Data Protection Act 2023 establishes rights for Data Principals and obligations for Data Fiduciaries processing their personal data. For SaaS companies with Indian users, this is live compliance — not a future concern.
DPDPA gap assessment
Feed in how the org currently handles Indian user data. Returns a gap assessment covering all Data Principal rights and Data Fiduciary obligations under the DPDPA 2023.
Under India's DPDPA 2023, assess our data processing practices for compliance. ORG: [description — e.g., "B2C SaaS, 200K Indian users, processes name, email, phone, payment info"] CURRENT PRACTICES: - Consent mechanism: [how consent is obtained and recorded] - Data access requests: [how users request access to their data] - Correction/erasure: [how users can correct or delete their data] - Grievance mechanism: [how users raise complaints] - Data retention: [how long data is kept and why] - Cross-border transfers: [if data leaves India, where and under what basis] For each Data Principal right, assess: | Right | DPDPA Section | Current Mechanism | Gap | Required Action | Priority | Rights to cover: Access | Correction | Erasure | Grievance | Nominee (in case of death/incapacity) Fiduciary obligations: Consent notice | Purpose limitation | Data minimization | Accuracy | Storage limitation | Security safeguards | Breach notification (72 hours) Flag: Does this org qualify as a Significant Data Fiduciary? What additional obligations apply?
Draft the consent notice
DPDPA requires consent notices to be clear, itemized, and given in the language the Data Principal understands. This generates a compliant notice for the primary data collection point.
Draft a DPDPA 2023-compliant consent notice for our primary data collection point. COLLECTION POINT: [e.g., "User registration form at app signup"] DATA COLLECTED: [list: name, email, phone, date of birth, payment info, usage analytics] PURPOSES: [list each purpose separately — e.g., "To create and manage your account," "To process payments," "To send product updates (optional)"] DATA PROCESSORS: [any third parties who process the data — e.g., "Stripe for payments, Mixpanel for analytics"] RETENTION PERIODS: [per data type] CROSS-BORDER: [does data leave India? To where?] Draft a consent notice that: - Is in plain language (8th grade reading level) - Itemizes each purpose separately with a consent checkbox - Clearly distinguishes between required consent (necessary) and optional consent - Includes contact details for the Data Protection Officer or Grievance Officer - States the right to withdraw consent and how to do it - Is compliant with DPDPA Section 7 (Notice) and Section 6 (Consent) requirements
Significant Data Fiduciary thresholds have not been finalized by the Data Protection Board as of 2025 — the government will notify thresholds by volume and sensitivity of data processed. If your client processes large volumes of sensitive data categories (health, financial, children's data), they should prepare for SDF designation and the additional obligations (DPIA, DPO appointment, algorithmic accountability) that come with it. Don't wait for the notification to start building the controls.