RCP-000-000-069-SECURITY-AUDIT-FRAMEWORK

{
“schema”: “CRAFT_AI_TO_AI_COMMUNICATION”,
“schema_version”: “1.1”,
“schema_profile”: “standalone-recipe”,
“recipe_id”: “RCP-000-000-069”,
“recipe_name”: “Security Audit Framework”,
“version”: “v2.00a-R”,
“original_version”: “v2.00a”,
“cookbook”: “Standalone (No Cookbook)”,
“category”: “Threat Preparation”,
“subcategory”: “Security Assessment”,
“difficulty”: “Easy”,
“status”: “Beta”,
“craft_flavors”: “CRAFT Cowork”,
“recommended_personas”: “Website Owner, Business Administrator, IT Coordinator”,

“summary”: {
“what_it_does”: “Structured self-assessment tool for reviewing website and digital asset security posture. The user describes their systems and configurations domain by domain; the AI applies a systematic checklist framework covering 5 security domains: authentication, data protection, access control, platform security, and integration security. Produces a prioritized action plan based on what the user reports. All assessment is based entirely on what the user describes — the AI cannot scan, test, or access any systems.”,
“what_it_is_not”: “Not a security scan, vulnerability assessment, penetration test, or compliance audit. Cannot test, scan, access, or interact with the user’s actual systems. Cannot verify whether reported configurations are correctly implemented, whether backups are restorable, or whether access controls are properly enforced. Cannot assess server-level or network-level security, or compliance with specific regulatory frameworks (HIPAA, PCI-DSS, GDPR, SOC 2). Does not replace professional security audits for regulated industries or high-risk environments.”,
“key_design_decisions”: [
“User-as-intelligence-source model — the AI guides the user through structured questions about their own systems. All findings are based on what the user reports, not what the AI has tested. This is the recipe’s foundational constraint and primary honesty mechanism.”,
“Domain-by-domain interactive rhythm — assessing one security domain at a time maintains focus, manages complexity for non-technical users, and provides checkpoint summaries so the user never loses track of their position across 5 domains.”,
“Three-tier audit depth — Quick (15 min), Standard (30-45 min), and Comprehensive (60+ min) tiers allow the user to choose their investment level. Standard covers 5 core questions per domain; Comprehensive adds 3 deeper questions per domain gated behind the depth parameter.”,
“‘I do not know’ as productive discovery — user uncertainty is reframed as actionable investigation items rather than failures. Every unknown gets specific guidance on WHERE to find the answer, including platform-specific paths where possible.”,
“Qualified severity language — findings use ‘based on what you have described, this may warrant attention’ rather than ‘this is a CRITICAL vulnerability.’ No numeric scores, letter grades, or definitive posture ratings. The AI cannot confirm severity without actual testing.”,
“Rule of 3 scope disclaimer — scope limitations are delivered at three natural points (opening, mid-flow after Domain 1, closing action plan) without over-disclaiming every domain.”,
“Active incident detection — if the user describes signs of a potential active breach during the routine audit, the recipe pauses and routes to incident response resources rather than continuing a self-assessment.”
],
“revision_notes”: “v2.00a → v2.00a-R (QA revision, H019). 11 gaps identified (1 CRITICAL, 4 HIGH, 4 MEDIUM, 2 LOW). Added 12 behavioral rules (was zero), 6 formal WAIT gates (was none — single-shot dump architecture), parameter coaching block with platform-specific examples, Rule of 3 professional disclaimers, honest scope boundaries. Removed false-authority severity ratings and ‘Good/Fair/Poor’ posture grades. Added explicit ‘What This Assessment Could Not Evaluate’ section. Fixed internal ID (055 → 069). Added mid-flow disclaimer and investigation HOW-TOs for unknown items.”
},

“parameters”: {
“count”: 5,
“required_count”: 5,
“optional_count”: 0,
“items”: [
{
“name”: “platform_type”,
“type”: “string”,
“required”: true,
“description”: “The website platform (WordPress, Squarespace, Shopify, etc.). Specificity enables platform-specific guidance in investigation HOW-TOs.”
},
{
“name”: “asset_list”,
“type”: “string”,
“required”: true,
“description”: “Digital assets to audit — website, email, payment processing, connected services, admin accounts, etc.”
},
{
“name”: “business_context”,
“type”: “string”,
“required”: true,
“description”: “Industry and data sensitivity — what kind of data the business handles (customer payments, personal info, contact forms, etc.).”
},
{
“name”: “audit_depth”,
“type”: “enum”,
“required”: true,
“values”: [“Quick”, “Standard”, “Comprehensive”],
“description”: “Quick (15 min, core questions only), Standard (30-45 min, full 5-question domains), or Comprehensive (60+ min, adds 3 deeper questions per domain).”
},
{
“name”: “last_audit_date”,
“type”: “string”,
“required”: true,
“description”: “When the user last performed a security review — a date or ‘never.’ Establishes baseline context.”
}
],
“interactive_inputs”: [
{
“name”: “domain_responses”,
“phase”: “Phases 2-6 (repeating)”,
“description”: “User answers to domain-specific security questions. 5 core questions per domain (Standard), plus 3 additional per domain (Comprehensive). ‘I do not know’ is a valid and expected answer.”
}
]
},

“behavioral_rules”: {
“count”: 12,
“items”: [
{“id”: “RULE-01”, “name”: “No System Access Claims”, “summary”: “Never claim to scan, test, penetrate, access, or interact with the user’s actual systems. This is a guided self-assessment. All analysis is based entirely on what the user reports about their own configurations.”},
{“id”: “RULE-02”, “name”: “Rule of 3 Professional Disclaimer”, “summary”: “Deliver scope limitation at three points: OPENING (self-assessment guide, not a security scan), MID-FLOW (findings based on what user reported — once after Domain 1), CLOSING (recommend professional assessment for critical or regulated environments).”},
{“id”: “RULE-03”, “name”: “I Do Not Know Is Valid”, “summary”: “Accept ‘I do not know’ as a valid and expected answer. Do not pressure user to guess. Flag unknown items as INVESTIGATE action items — not knowing is itself a useful finding.”},
{“id”: “RULE-04”, “name”: “Qualified Severity Language”, “summary”: “Use ‘based on what you have described, this may warrant priority attention’ rather than ‘this is a CRITICAL vulnerability.’ Use ‘potential concern,’ ‘warrants investigation,’ ‘consider prioritizing.'”},
{“id”: “RULE-05”, “name”: “No Fabricated Vulnerability Details”, “summary”: “Do not fabricate CVE numbers, exploit descriptions, or specific attack scenarios. Keep recommendations practical and general.”},
{“id”: “RULE-06”, “name”: “No Numeric Security Scores”, “summary”: “Do not assign numeric scores, letter grades, or definitive posture ratings. Use observational language: ‘Several areas suggest room for improvement’ or ‘configurations appear well-considered.'”},
{“id”: “RULE-07”, “name”: “Can vs Cannot Assess Distinction”, “summary”: “CAN assess from user reports: whether 2FA is enabled, password policy exists, backup procedures documented, access roles defined, plugins updated. CANNOT assess: actual SSL strength, real vulnerability exposure, whether backups work, whether access controls are enforced, server-level security.”},
{“id”: “RULE-08”, “name”: “Charitable Interpretation”, “summary”: “When user says ‘I think we have X,’ respond with ‘If X is active, that is a strong practice. I recommend verifying it is enabled for all admin accounts.’ Do not catastrophize uncertainty.”},
{“id”: “RULE-09”, “name”: “Adaptive Technical Depth”, “summary”: “Match language and question specificity to user’s apparent expertise. Technical users get deeper follow-ups; non-technical users get simple explanations and actionable delegation steps.”},
{“id”: “RULE-10”, “name”: “Domain Summaries as Checkpoints”, “summary”: “Each domain assessment ends with a clear summary (observations, strengths, investigation items, suggested actions) before moving to the next. User should understand their position in each domain as they go.”},
{“id”: “RULE-11”, “name”: “Investigation HOW-TOs”, “summary”: “For every ‘I do not know’ item, provide specific guidance on WHERE to find the answer. Platform-specific paths preferred (e.g., ‘Check Settings > Security & SSL’ for Squarespace). General guidance as fallback.”},
{“id”: “RULE-12”, “name”: “Active Incident Detection”, “summary”: “If user reports unusual access, suspected breach, or unauthorized changes, pause the audit. Recommend Cybersecurity Simulator recipes (RCP-016–020, RCP-060) or professional help immediately. Do not continue routine audit during potential incident.”}
]
},

“delivery_structure”: {
“phases”: 7,
“wait_gates”: 6,
“flow”: [
“Phase 1: Context and Scope Establishment — platform type, asset list, business context, audit depth, last audit date”,
“WAIT GATE 1 — collect scope information before starting domains”,
“Phase 2: Domain 1 — Authentication Security (2FA, passwords, admin access, recovery)”,
“WAIT GATE 2 — domain summary before proceeding”,
“Phase 3: Domain 2 — Data Protection (HTTPS, backups, customer data, retention)”,
“WAIT GATE 3 — domain summary + mid-flow disclaimer (once)”,
“Phase 4: Domain 3 — Access Control (permissions, offboarding, third-party access, logging)”,
“WAIT GATE 4 — domain summary before proceeding”,
“Phase 5: Domain 4 — Platform Security (updates, plugins, hosting security, WAF)”,
“WAIT GATE 5 — domain summary before proceeding”,
“Phase 6: Domain 5 — Integration Security (third-party services, API keys, payment processing)”,
“WAIT GATE 6 — domain summary before final report”,
“Phase 7: Comprehensive Assessment and Action Plan — overall observations, INVESTIGATE FIRST items with HOW-TOs, ADDRESS PROMPTLY items, STRENGTHEN OVER TIME opportunities, confirmed strengths, scope limitations disclosure, recommended next steps”
],
“output”: “7-phase interactive security self-assessment: scope establishment, 5 domain-by-domain Q&A sessions with checkpoint summaries, and a comprehensive prioritized action plan organized by urgency tier. Session length varies by depth (15-90 minutes).”
},

“relationships”: {
“family”: “Threat Preparation”,
“series”: “Threat Preparation (069)”,
“series_position”: “Standalone”,
“companion_recipes”: [],
“related_analytical”: [
{“id”: “RCP-000-000-016”, “relationship”: “Cybersecurity Simulator series (016-020) — incident response training and security policy documentation; audit findings can feed into policy components”},
{“id”: “RCP-000-000-060”, “relationship”: “Cybersecurity Simulator companion — additional incident response scenario”},
{“id”: “RCP-000-000-056”, “relationship”: “Emerging Threat Intelligence — complements self-assessment with current threat awareness”}
]
},

“lessons_learned”: [
{
“id”: “LL-CRPW-069-001”,
“category”: “PATTERN”,
“lesson”: “CRAFT_FLAVORS field ABSENT from WPRM metadata — 9th consecutive encounter in the pipeline (H077-H085), 6th surface form (2nd ABSENT). Auto-applied per REC-19 standing authority (no finding slot, no Richard disposition). ADD operation — field was never present in original (Auguste, Dec 2025, predates CRAFT_FLAVORS standardization) and was not added during H019 QA revision.”,
“source”: “REC-19 auto-apply, pipeline run 44”
},
{
“id”: “LL-CRPW-069-002”,
“category”: “ACCURACY”,
“lesson”: “NOTES FAQ dual-labeled recipes 016-020 as both ‘Cybersecurity Simulator’ and ‘Security Policy’ without clarification. Resolved by unifying the reference and clarifying that the Simulator recipes cover both incident response training and policy documentation. Residual from H019 QA revision that focused on behavioral rules rather than NOTES cross-reference consistency.”,
“source”: “CWK-ADM-079 F-01, pipeline run 44”
}
],

“pipeline_metadata”: {
“pipeline_run”: 44,
“recipe_number”: 43,
“standalone_number”: 39,
“handoff”: “H085”,
“date”: “2026-04-26”,
“project”: “CFT-PROJ-CP-067”
}
}

Show/Hide accordion — “Extended Information for the AI” section (AI-to-AI execution guidance, failure modes, tone calibration, common mistakes)