By Jackson Godwin | Cybersecurity Analyst & Penetration Tester. info@jacksontechnology.com.ng

SOC 2 Type II audits are among the most evidence-intensive compliance exercises a technology organization can undertake. Unlike a Type I report, which provides a point-in-time snapshot of control design, a Type II audit evaluates whether your controls actually operated effectively over an observation period — typically six to twelve months. That means auditors do not just want to see your policies. They want logs, access reviews, vulnerability scan reports, configuration snapshots, and incident records that prove your controls were running continuously, not just switched on the week before the audit.

For many security and compliance teams, evidence collection becomes the most time-consuming part of the entire SOC 2 process. Engineers manually export logs, screenshots are taken of dashboards, spreadsheets are populated with access review results, and the whole exercise is repeated every quarter. This approach is not only inefficient — it is error-prone, inconsistent, and difficult to defend under auditor scrutiny.

The good news is that a significant portion of SOC 2 Type II evidence collection can be automated using open-source tools — at zero licensing cost. This article walks through the practical implementation of an automated evidence collection pipeline, mapped directly to the SOC 2 Trust Services Criteria (TSC), so your team spends less time gathering evidence and more time building the controls that generate it.

SOC 2 Type II auditors are looking for evidence of consistent control operation over time — not a perfect environment. Automated, timestamped evidence collected continuously is far more defensible than manually assembled screenshots collected at audit time.

1. Understanding What SOC 2 Type II Evidence Actually Requires

Before automating evidence collection, your team must understand the five Trust Services Criteria categories and what kinds of evidence satisfy each one. The SOC 2 framework, developed by the American Institute of Certified Public Accountants (AICPA), is built around the following TSC categories:

• CC — Common Criteria (Security): the mandatory category covering logical access, change management, risk assessment, monitoring, and incident response
• A — Availability: uptime, capacity monitoring, disaster recovery, and business continuity
• C — Confidentiality: encryption, data classification, and information handling
• PI — Processing Integrity: accuracy and completeness of system processing
• P — Privacy: personal data collection, use, retention, and disposal

Most SaaS and technology organizations scope their SOC 2 report to Security (CC) and Availability (A) at minimum. The evidence requirements across these categories span access control logs, vulnerability management records, configuration compliance reports, change management tickets, incident logs, and availability metrics — all of which can be partially or fully automated.

2. The Case for Open-Source Tooling in SOC 2 Evidence Collection

Enterprise GRC platforms like Vanta, Drata, and Secureframe automate SOC 2 evidence collection through native integrations with cloud providers and SaaS tools. They are excellent products — but they carry annual licensing costs that are often prohibitive for early-stage startups, lean security teams, and organizations in cost-constrained markets. Open-source tooling provides a viable and often superior alternative for organizations willing to invest in setup and configuration.

The open-source approach offers several advantages beyond cost:

• Full transparency — you control exactly what evidence is collected, how it is stored, and how it is formatted for auditors
• No vendor dependency — your evidence pipeline does not break if a SaaS vendor changes their API or pricing
• Customization — you can tailor collection logic precisely to your environment, your auditor's evidence preferences, and your specific control implementations
• Auditability of the pipeline itself — your evidence collection scripts can be version-controlled in Git, demonstrating to auditors that the collection process is itself controlled and documented

A well-documented open-source evidence pipeline stored in a version-controlled repository is often more credible with experienced SOC 2 auditors than a GRC platform screenshot — because it demonstrates that your team understands and owns the controls, not just the tooling.

3. Open-Source Tools Mapped to SOC 2 Trust Services Criteria

The following table maps the most effective open-source tools to specific SOC 2 TSC requirements. Each tool produces machine-readable or structured output that can be ingested into your evidence repository automatically on a scheduled basis.

Evidence Type	Open-Source Tool	SOC 2 TSC Mapping	Output Format
Access Control Logs	Osquery	CC6.1, CC6.2, CC6.3	JSON / CSV logs
Vulnerability Scanning	OpenVAS / Greenbone	CC7.1, A1.2	PDF / XML reports
Configuration Compliance	Lynis	CC6.6, CC7.2	Audit report text
Network Traffic Analysis	Zeek (Bro)	CC6.7, CC7.2	Log files / JSON
Log Aggregation & SIEM	Wazuh	CC7.2, CC7.3, CC7.4	Dashboard + alerts
File Integrity Monitoring	OSSEC / Wazuh FIM	CC6.1, CC7.2	Alert logs
Cloud Config Auditing	Prowler (AWS/GCP/Azure)	CC6.1, CC6.6, CC7.1	HTML / JSON / CSV
Container Security	Trivy	CC7.1, A1.2	JSON / SARIF reports
Policy Compliance	Chef InSpec	CC2.1, CC6.1, CC7.2	JSON / HTML reports
Secret Scanning	Gitleaks / TruffleHog	CC6.1, CC6.6	JSON findings report
Uptime & Availability	Uptime Kuma	A1.1, A1.2	Dashboard + history

4. Building Your Automated Evidence Collection Pipeline

The goal is a pipeline that runs on a defined schedule, collects evidence from each tool, timestamps and stores the output in a structured repository, and generates a summary report that maps each piece of evidence to its corresponding SOC 2 control. Here is how to build it layer by layer.

Layer 1 — Endpoint and System Telemetry with Osquery

Osquery turns your operating system into a queryable database. It is one of the most powerful open-source tools for SOC 2 evidence collection because it can answer almost any question about system state in a structured, exportable format — user accounts, running processes, installed software, network connections, file permissions, and more.

Install Osquery on all in-scope endpoints and schedule the following queries to run daily, with output written to your evidence store:

SELECT * FROM users WHERE shell != '/usr/sbin/nologin';

SELECT * FROM logged_in_users;

SELECT * FROM listening_ports WHERE address != '127.0.0.1';

SELECT * FROM file WHERE path = '/etc/sudoers';

These queries provide continuous evidence for CC6.1 (logical access), CC6.2 (user provisioning), and CC6.3 (access removal). Schedule them using osqueryd with a configuration file and pipe the JSON output to your central log store via Filebeat or Fluent Bit.

Layer 2 — Vulnerability Management Evidence with OpenVAS

OpenVAS (now packaged as Greenbone Community Edition) is an enterprise-grade open-source vulnerability scanner that satisfies SOC 2 CC7.1 and A1.2 evidence requirements. Configure weekly authenticated scans of all in-scope systems and export reports in PDF or XML format automatically after each scan run.

The key for SOC 2 evidence is not just running scans — it is demonstrating that findings are tracked and remediated within defined SLAs. Implement a simple findings tracker in a Git repository or a lightweight issue tracker like Gitea, and document your vulnerability remediation SLA policy (for example, Critical within 15 days, High within 30 days). The combination of scan reports plus a remediation tracking record satisfies the full CC7.1 evidence requirement.

Layer 3 — Cloud Configuration Auditing with Prowler

For organisations running workloads on AWS, GCP, or Azure, Prowler is the most comprehensive open-source cloud security posture auditing tool available. It checks hundreds of configuration controls across IAM, networking, logging, encryption, and monitoring, and maps findings directly to CIS Benchmarks, SOC 2, ISO 27001, and other frameworks.

Run Prowler on a weekly schedule using a CI/CD pipeline or a cron job on a dedicated audit workstation:

prowler aws --compliance soc2 --output-formats html json csv

prowler aws --compliance soc2 -M csv html -o /evidence/prowler/$(date +%Y-%m-%d)/

Store each weekly output in a dated folder within your evidence repository. Over a six-month observation period, this creates an automatically timestamped record of your cloud configuration compliance trajectory — exactly what SOC 2 Type II auditors need to evaluate control operating effectiveness over time.

Layer 4 — Log Aggregation and Alerting with Wazuh

Wazuh is an open-source security information and event management (SIEM) platform that combines log aggregation, file integrity monitoring, intrusion detection, and compliance reporting in a single deployable stack. For SOC 2 Type II, Wazuh is particularly valuable because it covers multiple TSC requirements simultaneously:

• CC7.2 — System monitoring: Wazuh aggregates logs from all agents and generates alerts for anomalous activity
• CC7.3 — Evaluation of security events: Wazuh's rule engine classifies events by severity and generates incident tickets
• CC7.4 — Incident response: Wazuh active response can trigger automated containment actions and log all response activity
• CC6.1 — File integrity monitoring: Wazuh FIM tracks changes to critical system files and configuration files in real time

Deploy Wazuh agents on all in-scope systems and configure the Wazuh dashboard to generate monthly compliance summary reports. Export these reports as PDF artefacts and store them in your evidence repository with the observation period dates clearly labelled.

Layer 5 — Infrastructure as Code Compliance with Chef InSpec

Chef InSpec allows you to write human-readable compliance tests that validate whether your systems meet defined security baselines. For SOC 2 Type II, InSpec profiles can be run against your servers, containers, and cloud resources on a scheduled basis, producing structured pass/fail reports that map directly to your control matrix.

The AICPA has published SOC 2 InSpec profiles, and the DevSec project maintains hardening profiles for Linux, SSH, and web servers that align with SOC 2 CC6.6 and CC7.2. Run InSpec as part of your CI/CD pipeline to generate compliance evidence at every deployment:

inspec exec https://github.com/dev-sec/linux-baseline --reporter json:evidence/inspec/$(date +%Y-%m-%d)-linux.json

This approach generates evidence that your infrastructure meets security baselines not just at audit time but at every code deployment — demonstrating continuous control operation rather than point-in-time compliance.

5. Structuring Your Evidence Repository

Automated evidence collection is only valuable if the output is organised in a way that auditors can navigate efficiently. Structure your evidence repository — whether in Git, an S3 bucket, or a network share — using the following folder hierarchy:

/evidence/

  /access-control/          # Osquery user and access logs

  /vulnerability-mgmt/      # OpenVAS scan reports by date

  /cloud-config/            # Prowler output by week

  /system-monitoring/       # Wazuh monthly reports

  /config-compliance/       # InSpec run outputs

  /availability/            # Uptime Kuma exports

  /change-management/       # Git commit logs, PR records

  /incident-response/       # Incident tickets and postmortems

  /access-reviews/          # Quarterly access review exports

Each folder should contain a README file that maps the evidence inside it to specific SOC 2 TSC controls. This README becomes the navigation guide for your auditor and dramatically reduces the time spent in auditor information requests (also known as PBC — Provided By Client — lists).

6. Automating the Evidence Collection Schedule

Once your tools are deployed and configured, automate the evidence collection runs using a combination of cron jobs, CI/CD pipelines, and cloud-native schedulers. A practical schedule for a SOC 2 Type II observation period looks like this:

• Daily: Osquery system telemetry queries, Wazuh log collection, Uptime Kuma availability records, Gitleaks secret scanning on new commits
• Weekly: Prowler cloud configuration audit, OpenVAS vulnerability scans, Lynis system hardening audit on representative endpoints
• Monthly: Wazuh compliance summary report export, InSpec profile runs across all in-scope systems, and access review evidence export from your identity provider
• Quarterly: Full access review with manager sign-off documentation, vendor risk review records, business continuity test evidence

All scheduled runs should write output to your evidence repository with the collection date embedded in the filename or folder path. This timestamp discipline is essential — auditors need to verify that evidence was collected during the observation period, not assembled retroactively.

7. Common Mistakes That Undermine SOC 2 Evidence Quality

• Collecting evidence only at audit time — SOC 2 Type II requires evidence of continuous operation across the full observation period, not a burst of activity in the final month
• Storing evidence in personal drives or email — all evidence must be in a controlled, access-restricted repository with an audit trail of who accessed or modified it
• Missing remediation records — scan reports showing vulnerabilities without corresponding remediation tickets and closure evidence are incomplete and will generate auditor findings
• No evidence of access reviews — provisioning logs alone do not satisfy CC6.2 and CC6.3; you need documented quarterly reviews showing that access was evaluated and unnecessary permissions removed
• Unversioned collection scripts — your evidence collection automation should itself be in version control, demonstrating that the collection process is controlled and has not been tampered with
• Inconsistent date formats and naming conventions — evidence with unclear dates or inconsistent naming forces auditors to spend time deciphering your repository, increasing the risk of misinterpretation

The single most common reason SOC 2 Type II audits take longer than expected is disorganized evidence. An auditor who cannot find the evidence they need will generate additional information requests — each one adding days to your timeline and cost to your audit bill.

Conclusion

Automating SOC 2 Type II evidence collection with open-source tools is not only cost-effective — it produces higher-quality, more consistent, and more defensible evidence than manual collection processes. Tools like Osquery, Prowler, Wazuh, OpenVAS, Chef InSpec, and Uptime Kuma, when configured correctly and scheduled consistently, create a continuous compliance posture that aligns precisely with what SOC 2 Type II auditors evaluate.

The investment required is primarily in the initial setup and integration of these tools into your existing infrastructure. Once the pipeline is running, evidence collection becomes largely hands-free — freeing your security and engineering teams to focus on control improvement rather than audit preparation. The result is a SOC 2 Type II report that reflects genuine, continuously operating controls rather than a point-in-time compliance effort assembled under audit pressure.

If your organisation needs a SOC 2 readiness assessment, gap analysis, or support designing an automated evidence collection pipeline tailored to your specific infrastructure and audit scope, reach out directly for a consultation.

About the Author

Jackson Godwin is a Cybersecurity Team Lead and Penetration Tester with over 4 years of experience delivering VAPT engagements, cloud security reviews, and compliance advisory services across financial institutions, fintech organizations, and government agencies. He specialises in SOC 2, PCI-DSS, ISO 27001, and cloud security assessments and has led 25+ security engagements across web, mobile, cloud, and network environments.

Contact: info@jacksontechnology.com.ng