Automating ISO 27001 / SOC 2 Compliance Evidence Collection with n8n

A well-designed audit questionnaire, with a timestamped trail in Supabase, covers half of ISO 27001 or SOC 2 compliance work: the declarative half, where someone answers "yes, MFA is enabled on admin accounts" or "yes, backups run every night." The other half — the one an external auditor systematically asks for — is technical evidence: the screenshot of the MFA configuration in the admin console, the log of successful backups over the last thirty days, the list of access rights revoked within 24 hours of an employee's departure. That's the evidence that takes the longest to gather by hand, and it goes stale the fastest between two audit cycles.

Declarative evidence and technical evidence are two different things

The guided questionnaire bot in the Compliance & Audit Pack excels at the first category: it walks someone through an audit protocol, timestamps each answer, and files it in Supabase, with automatic follow-ups on incomplete records. That's exactly what's needed to document intentions and processes. But an ISO 27001 auditor won't settle for a "yes" answer to "are access rights reviewed regularly?" — they want to see the export of the last review, its date, and the accounts that were actually disabled.

This gap between declarative and technical evidence isn't new: the idea of tying audit evidence to the real state of systems, continuously rather than at a fixed control date, traces back to Vasarhelyi and Halper's foundational paper, The Continuous Audit of Online Systems (1991), which describes one of the first continuous-monitoring systems deployed in production, on AT&T's billing data. More than three decades later, the problem they described — controls checked at a single point in time rather than continuously — remains the main complaint about ISO 27001 and SOC 2 audits run purely by questionnaire.

Building an evidence collector in n8n

The principle: a separate n8n workflow, dedicated to technical evidence, that feeds the same audit trail as the conversational bot rather than replacing it.

1. Schedule Trigger — a weekly run per control family (access, backups, security patches, encryption). Our Schedule Trigger and cron expressions guide covers the syntax if you want to stagger each family on a different day.
2. HTTP Request nodes, one per source — read-only queries against the relevant APIs: the GitHub API for branch protection rules and 2FA enforcement on contributors, your cloud provider's API for IAM roles and backup logs, your SSO provider's API for account MFA status. Every credential used here should be a read-only scoped token — our guide to securing API credentials in n8n covers restricting scopes to the strict minimum.
3. Set (Edit Fields) node — normalizes each heterogeneous API response into a common shape: control_id, source, raw_value, collected_at.
4. Supabase node — inserts the normalized row into a compliance_evidence table, following the same principle as the timestamped audit trail webhook already used by the pack for declarative answers: a single write point, a constant format, a server-side timestamp that can't be forged.

The result after a few weeks: a table that holds both the human answers from the questionnaire and the technical evidence collected automatically, linked by the same control_id.

Having each piece of evidence evaluated by a constrained LLM

A raw API response (an IAM configuration JSON, a list of commits on a protected branch) isn't readable for a leadership review, let alone directly usable in an audit report. That's where a language model helps — provided it's tightly constrained:

• The prompt receives the exact description of the expected control ("MFA must be enabled for 100% of accounts with an admin role") and the raw evidence collected.
• A Structured Output Parser forces a response in the shape { control_id, status: "compliant" | "non_compliant" | "needs_review", justification } — never free text you'd have to re-read by hand.
• The needs_review status is deliberately built in for ambiguous cases: an "I can't decide" signal beats false certainty. A model with no option to express uncertainty tends to decide anyway, often wrongly.

Before trusting this prompt on real controls, test it against a set of evidence already qualified manually from a past audit — the same evaluation logic described in our article on n8n evaluations for AI workflows, applied here to diagnosis reliability rather than chatbot answer quality.

Routing non-compliance findings to human validation

No evidence marked non_compliant or needs_review should automatically close or dismiss a compliance action — the stakes (a certification, a B2B customer's trust) are too high for full autopilot. The If node routes both statuses to a Slack alert followed by a Wait node with human validation: the person responsible for compliance confirms, corrects the status, or triggers a corrective action before the record moves forward. compliant evidence, on the other hand, can archive directly — the time saved concentrates where it matters, on the real gaps.

Generating the audit report from both sources

Once the audit_responses (declarative) and compliance_evidence (technical) tables are fed continuously, the pack's AI-generated summary report workflow only needs one extension: reading both tables instead of one before the synthesis step. The final report then presents, control by control, the declared answer alongside its matching technical evidence — exactly the structure an ISO 27001 or SOC 2 auditor expects from an evidence file, with weeks of manual collection removed.

A study published in 2026 in the journal Software (MDPI), Integrating Continuous Compliance into DevSecOps Pipelines: A Data Engineering Perspective, proposes a fairly similar architecture for continuous development environments: evidence collected automatically at every pipeline stage, timestamped and queryable, rather than reconstructed at the last minute before an audit. The principle transposed here to n8n is the same — replacing the one-time snapshot with a continuous stream of already-organized evidence.

Common pitfalls

• Keeping only the LLM's verdict, not the raw evidence — an auditor wants to see the original screenshot or API response, not just "compliant" written by a model. Always archive the source evidence alongside its evaluation.
• API tokens that are too broad — a write-capable credential used for simple reads is a disproportionate security risk relative to the need; stay strictly read-only.
• A prompt with no examples of what counts as valid evidence — without a few annotated examples in the system message, the model improvises its own definition of "compliant," rarely aligned with your actual framework.
• Forgetting to date how fresh evidence is — a three-month-old backup proof is worthless for a control meant to be checked weekly; the collected_at field should appear explicitly in the report, not just in the database.

Going further

This technical evidence collector complements, without replacing, the Compliance & Audit Pack (€149): the conversational bot and automated follow-ups cover the declarative side, and this workflow adds the technical side on the same Supabase tables, for a complete audit file generated continuously instead of scrambled together under deadline at each certification cycle.