Audit Logging Architecture Design Prompt

This prompt is designed for security architects and platform engineers who need to perform a structured design review of an audit logging architecture before a single line of code is written. The core job-to-be-done is to take a system design document and produce a rigorous, verifiable audit coverage matrix. This matrix must confirm that every critical event—authentication, authorization, data access, and configuration change—is captured in a tamper-proof, non-repudiable trail. The ideal user is someone who understands the system's data flow and trust boundaries and needs to translate a design diagram into a concrete set of logging requirements, retention policies, and SIEM integration specifications.

To use this prompt effectively, you must provide a detailed system design document as the [SYSTEM_DESIGN] input. This document should include component diagrams, data flow descriptions, trust boundaries, and a list of critical actions within the system. The prompt is not a runtime log analyzer; it will not parse raw log files or query a live SIEM. It operates purely at the design review level. A common failure mode is providing an incomplete or high-level design, which will result in a coverage matrix full of 'unknown' or 'assumed' entries. The output is only as strong as the design document you feed it. For high-risk or regulated environments, the generated matrix should be treated as a starting point for a formal review, not the final audit artifact.

Do not use this prompt if you are looking for a real-time threat detection rule or an incident response playbook. It is also the wrong tool if you need to analyze an existing, running system's logs to find gaps—that requires a runtime analysis prompt. Instead, use this prompt during the architecture review phase, right after the initial system design is drafted and before implementation begins. The next step after generating the audit coverage matrix is to feed the identified gaps back into the design document and re-run the prompt to verify closure, ensuring that catching missing audit events remains cheap and doesn't force a costly re-architecture later.

This prompt template is designed to be pasted directly into your AI workspace. It instructs the model to act as a security architect reviewing an audit logging design. The square-bracket placeholders must be replaced with your specific system context, design documents, compliance requirements, and risk tolerance before execution. The prompt is structured to produce a consistent, evaluable output that can be fed into downstream review or automation pipelines.

codeCopy
You are a security architect specializing in audit logging and non-repudiation for distributed systems.

Review the following system design and produce a comprehensive audit logging architecture assessment.

## SYSTEM CONTEXT
[SYSTEM_DESIGN_DOCUMENT]

## COMPLIANCE REQUIREMENTS
[COMPLIANCE_FRAMEWORKS]

## EXISTING LOGGING INFRASTRUCTURE
[CURRENT_LOGGING_STACK]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with these exact fields:
{
  "audit_coverage_matrix": [
    {
      "event_category": "authentication | authorization | data_access | configuration_change | privilege_escalation | api_call | admin_action",
      "specific_event": "string describing the auditable event",
      "current_coverage": "covered | partial | missing",
      "log_fields_required": ["field1", "field2"],
      "retention_requirement": "string with duration and justification",
      "integrity_mechanism": "hash_chain | signing | append_only_store | blockchain | none",
      "siem_mapping": "string describing SIEM rule or detection"
    }
  ],
  "integrity_architecture": {
    "tamper_detection": "string describing mechanism",
    "chain_of_custody": "string describing log lifecycle",
    "non_repudiation_controls": ["control1", "control2"],
    "log_injection_risks": [
      {
        "vector": "string",
        "severity": "critical | high | medium | low",
        "mitigation": "string"
      }
    ]
  },
  "retention_and_lifecycle": {
    "hot_storage_days": number,
    "warm_storage_days": number,
    "cold_storage_years": number,
    "deletion_verification": "string",
    "legal_hold_process": "string"
  },
  "siem_integration_requirements": {
    "log_format": "json | cef | leef | syslog | custom",
    "required_fields_for_correlation": ["field1"],
    "alert_rules": [
      {
        "rule_name": "string",
        "condition": "string",
        "severity": "string",
        "response_playbook": "string"
      }
    ]
  },
  "gaps_and_recommendations": [
    {
      "gap": "string",
      "risk": "string",
      "recommendation": "string",
      "priority": "critical | high | medium | low",
      "effort_estimate": "small | medium | large"
    }
  ],
  "compliance_mapping": [
    {
      "requirement_id": "string from [COMPLIANCE_FRAMEWORKS]",
      "requirement_text": "string",
      "satisfied": true | false | "partial",
      "evidence_location": "string describing where proof is logged"
    }
  ]
}

## EVALUATION CRITERIA
Before returning the output, verify:
1. Every event category in the coverage matrix has at least one auditable event defined.
2. All critical-severity log injection risks have a concrete mitigation.
3. Non-repudiation controls cover creation, transmission, storage, and retrieval.
4. Retention periods align with the longest requirement in [COMPLIANCE_FRAMEWORKS].
5. SIEM alert rules include both threshold-based and anomaly-based detections.
6. No recommendation is stated without a corresponding gap and risk.

## INSTRUCTIONS
- If [SYSTEM_DESIGN_DOCUMENT] is insufficient to assess a category, mark coverage as "unknown" and explain what information is missing in the gaps section.
- Do not invent compliance requirements beyond what is specified in [COMPLIANCE_FRAMEWORKS].
- Flag any architecture where logs can be modified or deleted by the same role that generates them.
- Return ONLY valid JSON. No markdown fences, no commentary outside the JSON object.

To adapt this prompt, replace each placeholder with concrete details. [SYSTEM_DESIGN_DOCUMENT] should contain your architecture diagrams, service descriptions, data flow documentation, and existing logging configurations. [COMPLIANCE_FRAMEWORKS] should list specific standards like SOC 2, PCI DSS 4.0, HIPAA, or GDPR with the relevant control IDs. [CURRENT_LOGGING_STACK] describes your existing ELK, Splunk, Datadog, or cloud-native logging infrastructure. [CONSTRAINTS] captures budget limits, latency requirements, team capabilities, or technology restrictions that shape feasible recommendations.

Before using this prompt in production, test it against known architectures where you already understand the gaps. Run it against a design you know has missing audit coverage and verify the model identifies those gaps. Test edge cases: designs with no logging at all, designs where logs and application share credentials, and designs spanning multiple cloud providers. Validate the JSON output against the schema programmatically before accepting results. For high-assurance environments, require a human security architect to review the output before it becomes part of an audit record or compliance submission.

The audit logging architecture prompt is designed to operate as a structured analysis step inside a broader security design review, not as a standalone report generator. The implementation harness should treat the LLM call as one component in a pipeline that validates outputs, enforces schema compliance, and routes findings to the appropriate review queue. Because audit logging failures can create compliance gaps and blind spots during incident response, the harness must enforce non-negotiable output contracts before any result reaches a human reviewer or downstream system.

Wire the prompt into your workflow by constructing a request object that populates the required placeholders: [SYSTEM_DESIGN_DOC] receives the architecture document or design spec; [COMPLIANCE_FRAMEWORKS] accepts a list of applicable standards (SOC 2, HIPAA, PCI DSS, ISO 27001); [EXISTING_LOG_INFRASTRUCTURE] describes current logging pipelines, SIEM tools, and retention policies; and [RISK_TOLERANCE] sets the review depth. After the model returns its response, run a schema validator that checks for the required output structure: an audit coverage matrix with columns for event category, source system, logged fields, integrity mechanism, retention period, and SIEM integration status. Reject any response missing these fields and retry with a repair prompt that includes the validation error. For high-risk domains, route outputs with critical_gaps: true or non_repudiation_risk: high directly to a human approval queue before the findings enter the architecture decision record.

Instrument the harness with structured logging that captures the prompt version, model used, input document hash, output schema validation result, retry count, and reviewer identity. This audit trail is essential when the prompt itself is used to design audit logging—you must demonstrate that the review tooling meets the same integrity standards it enforces. Avoid treating the LLM output as final architecture guidance. Instead, use it as a structured analysis artifact that a security architect reviews, annotates, and signs off on. The harness should store both the raw model output and the human-reviewed version, with diffs, so that future audits can distinguish between AI-generated findings and human architectural decisions.