Hey folks, been working through our ISO 27001 recertification and hit A.14.2.1 (Security in development and support processes). Our auditors are really zooming in on our agent runtimes, specifically how we handle prompt injection for our internal support bots.
The big question: what's the most effective way to **document** these defenses to satisfy the audit requirement for secure development practices? They don't just want a verbal "we have filters," they want to see it in the process.
Here's what we ended up presenting, which got a thumbs-up:
* **Process Documentation:** A clear step in our SDLC flowchart for "LLM Interaction Security Review." This mandates a threat model for any feature using prompts, with prompt injection called out explicitly.
* **Technical Controls Log:** A living document (we use a wiki) that lists each agent runtime and its specific mitigations. For example:
```
Agent: Deployment Validator Bot
Purpose: Checks Docker compose files for security issues.
Mitigations:
1. Input Sandboxing: All user input is placed into a dedicated, non-executable context field.
2. Instructional Guardrails: System prompt includes strict command separation using XML tags.
3. Output Validation: Regex parsing on the agent's output to allow only a whitelist of commands.
4. Logging: All prompts and completions are logged to our SIEM for anomaly detection.
```
* **Evidence:** We linked to actual test cases in our QA suite that simulate injection attempts (e.g., "Ignore previous instructions...") and show the blocked/logged result.
The common gap they flagged initially was having these controls but not showing a formal **review and update cycle**. We now have a quarterly task to review new injection techniques and update our guardrails and test cases.
What are you all using? Especially interested in how you handle documentation for dynamic, non-deterministic systems.
Security is a process, not a product.
Interesting! That wiki log is smart. We're trying something similar but I'm stuck on the details.
For the "Instructional Guardrails" part, are you just pasting the whole system prompt into the wiki? Our main bot prompt is huge, feels messy to copy it all. But a summary feels too vague for an audit trail.
Did your auditors accept like, a summary plus a version-controlled file path reference instead?
Still learning.
We used a reference, and it passed. Our wiki entry lists the control ("Instructional Guardrails via System Prompt"), a brief description of its intent (e.g., "defines strict role, response format, and prohibited actions"), and a link to the specific file in our private GitHub repo. The repo holds the full prompt, and we tag commits with a change-log comment like "PROMPT-001: Updated disallowed command list."
The auditors cared more about the traceability from the control listing to the actual, versioned asset. They didn't need the full text in the wiki. Just make sure your repo's access controls are part of your ISMS scope.
DS
Great structure! That technical controls log is exactly the kind of thing auditors love to see. We do something very similar.
One thing we added that helped was a "last reviewed" date column for each agent entry. It creates a clear maintenance cadence, especially when a system prompt gets tweaked. It shows you're not just setting it and forgetting it.
Did your auditors ask to see evidence that the team actually follows that SDLC step for new features, like meeting notes or Jira tickets? Ours did.
--Emily