--- title: "How to Automate ISO 27001 Annex A.8 Evidence Collection with Screenshots" summary: "Yes. You can automate ISO 27001 A.8 evidence collection using tools that capture screenshots of access rights, cryptography settings, and system configurations. This guide explains what auditors actually check for technological controls and where traditional GRC platforms fall short." publishedAt: "2026-04-26" author: "Screenata Team" image: "/static/how-to-automate-iso-27001-annex-a8-evidence-collection-with-screenshots.jpg" tags: ["ISO 27001", "Annex A.8", "Technological Controls", "Evidence Collection", "ISMS", "Compliance Automation"] category: "Compliance" featured: false structuredData: "@context": "https://schema.org" "@type": "FAQPage" mainEntity: - "@type": "Question" name: "What are ISO 27001 A.8 controls?" acceptedAnswer: "@type": "Answer" text: "ISO 27001:2022 Annex A.8 covers 34 technological controls (A.8.1 to A.8.34). These controls dictate how an organization manages IT security, including endpoint protection, cryptography, configuration management, data masking, and access rights." - "@type": "Question" name: "What evidence do auditors need for A.8.24 Cryptography?" acceptedAnswer: "@type": "Answer" text: "Auditors require visual proof that cryptography is actively used to protect data. Acceptable evidence includes screenshots of AWS KMS key rotation settings, database encryption toggles, TLS configuration files, and certificate management dashboards." - "@type": "Question" name: "Can GRC platforms automate all ISO 27001 Annex A.8 evidence?" acceptedAnswer: "@type": "Answer" text: "No. While API-based GRC tools can read basic cloud infrastructure settings, they cannot capture UI-level configurations in custom internal tools, legacy systems, or third-party SaaS applications that lack open APIs. These require automated screenshot capture." --- ISO 27001 certification audits require rigorous evidence for every technological control listed in your Statement of Applicability. When auditors evaluate Annex A, they don't just want to read your ISMS policies—they want to see actual system configurations, encryption keys, and access management rules. While many teams try to manage this documentation manually, capturing screenshots of 34 different technological controls across your entire infrastructure takes weeks. Automation is the only practical way to keep this evidence current between audit cycles. This guide covers what auditors actually expect for A.8 controls and how automated evidence collection replaces the manual screenshot grind. ## What Are ISO 27001 A.8 Technological Controls? In the ISO 27001:2022 update, the standard consolidated its controls into four themes. Annex A.8 is the "Technological" theme. It is the largest category in the standard, containing 34 distinct controls (A.8.1 through A.8.34). If A.5 (Organizational) is the paperwork and A.6 (People) is the HR process, A.8 is the actual IT reality of your company. It covers how you configure servers, encrypt databases, manage privileged access, and prevent data leaks. For a SaaS company, A.8 is where the bulk of the technical audit happens. You can write a perfect cryptography policy, but if you cannot prove that your production database is actually encrypted, you will receive a non-conformity. ## What Evidence Do ISO 27001 Auditors Actually Check for A.8? Auditors approach technological controls by asking for a sample of systems and requesting proof that the controls operate as described in your ISMS. They generally divide A.8 into four major testing areas. ### Configuration and Endpoint Management Controls like **A.8.1 (User endpoint devices)** and **A.8.9 (Configuration management)** require proof that you enforce baselines. Auditors want to see: * Mobile Device Management (MDM) portal screenshots showing active enforcement of disk encryption and screen lock policies. * Infrastructure-as-Code (IaC) repository settings showing branch protection rules. * Cloud provider configuration baselines (like AWS Security Hub scores or GCP Security Command Center policies). ### Access and Authentication Controls like **A.8.2 (Privileged access rights)** and **A.8.5 (Secure authentication)** map closely to SOC 2 logical access requirements. Auditors want to see: * Screenshots of your Identity Provider (Okta, Google Workspace) showing MFA enforcement for all users. * IAM role lists in AWS proving that only specific engineers have production database access. * Evidence of regular access reviews, including the tickets or logs showing when access was revoked for offboarded employees. ### Cryptography and Data Protection The 2022 update introduced heavy emphasis on data protection with **A.8.11 (Data masking)**, **A.8.12 (Data leakage prevention)**, and **A.8.24 (Use of cryptography)**. Auditors want to see: * AWS KMS or Azure Key Vault screenshots showing active key rotation policies. * Database configuration panels showing encryption-at-rest is toggled on. * Application code snippets or configuration files showing TLS 1.2+ enforcement for data in transit. * Settings in your customer support tools showing how PII or credit card numbers are masked from agents. ### Logging and Monitoring Controls like **A.8.15 (Logging)** and **A.8.16 (Monitoring activities)** prove that you can detect when something goes wrong. Auditors want to see: * Datadog, Splunk, or CloudWatch configuration screens showing log retention periods (usually 90 to 365 days). * Screenshots of alerting rules configured for failed login spikes or unauthorized access attempts. | Control ID | Control Name | Acceptable Visual Evidence | | :--- | :--- | :--- | | **A.8.2** | Privileged access rights | Screenshot of AWS IAM showing users attached to the `AdministratorAccess` policy. | | **A.8.9** | Configuration management | Screenshot of Terraform Cloud workspace settings or GitHub Actions deployment requirements. | | **A.8.15** | Logging | Screenshot of centralized logging tool showing retention policy settings and active event ingestion. | | **A.8.24** | Use of cryptography | Screenshot of RDS database settings showing "Encryption: Enabled" and the associated KMS key. | ## What ISO 27001 Evidence Cannot Be Automated with GRC Tools Many teams buy a GRC platform expecting it to handle the entire ISO 27001 audit. Tools like Drata, Vanta, and Secureframe are excellent at reading APIs from major cloud providers. They can look at AWS and verify that your RDS instances are encrypted. But here is where traditional GRC automation stops: **Custom Internal Tools** If your customer success team uses a proprietary admin panel to reset user passwords or manage accounts, your GRC platform's API cannot see it. You still have to manually log in, take a screenshot of the permission matrix, and upload it as evidence for A.8.2. **Niche SaaS Applications** GRC platforms only build integrations for the most popular enterprise tools. If you use a specialized industry tool for deployment, monitoring, or HR, you will have to gather that evidence manually. **Visual State Requirements** Sometimes auditors simply reject JSON API outputs. A JSON file containing `"mfa_enabled": true` is easily manipulated. Many ISO 27001 auditors still prefer visual proof—a timestamped screenshot of the actual admin dashboard showing the setting toggled on. GRC tools pull data, but they rarely capture the visual state of the UI. When you rely entirely on API-based tools, you end up with a "20% manual gap." That 20% usually consists of complex, application-level controls that require hours of manual screenshotting right before the Stage 2 audit. ## How Do You Automate ISO 27001 A.8 Control Evidence? To fully automate Annex A.8 evidence, you need a system that behaves like an internal auditor—something that can navigate your actual applications and capture the visual proof. This is where AI agents handle the manual work. Instead of an engineer spending a Friday afternoon taking 50 screenshots of different AWS regions and Okta panels, an AI agent runs a scheduled workflow. It logs into the required systems, navigates to the specific configuration pages (like the KMS key rotation setting for A.8.24 or the MFA enforcement policy for A.8.5), and captures a timestamped screenshot. The agent then packages these screenshots into a PDF evidence pack, mapping each image directly to the corresponding ISO 27001 control ID. When the auditor asks for proof of your technological controls, you hand them a clean, standardized document showing the exact state of your systems. This approach satisfies the auditor's need for visual, contextual proof while completely removing the engineering burden of manual evidence collection. ## Learn More About ISO 27001 Evidence Automation For a complete look at how to eliminate manual screenshot collection across your entire Information Security Management System, see our guide on [automating ISO 27001 evidence collection](/resources/blog/how-to-automate-iso-27001-evidence-collection), including how to map automated workflows to organizational, physical, and people controls.