A.8.8 Management of technical vulnerabilities: evidence

What A.8.8 technical vulnerability management asks for in practice

An auditor or customer questionnaire that asks how vulnerabilities are handled is testing A.8.8 Management of technical vulnerabilities. In short, the control asks the organization to find out about technical vulnerabilities in the information systems it uses, judge how exposed it is to them, and then take proportionate action. The control is about a repeating process that stays current, not a one-time scan, and the organization must be able to show that the process runs. The control has three working parts. The first is obtaining vulnerability information, which means knowing which software, operating systems, network devices and cloud services are in use and having a reliable source of news about flaws in them. The second is evaluating exposure, which asks whether a reported flaw actually affects a given system, whether the system is reachable, and how much damage a compromise would cause. The third is taking measures, which covers patching, configuration changes, compensating controls or a documented decision to accept the risk. A.8.8 merges two controls from the 2013 edition, A.12.6.1 on management of technical vulnerabilities and A.18.2.3 on technical compliance review, so the expectation now includes checking that systems actually conform to the organization's own security configuration. The risk the control addresses is simple: attackers exploit known flaws in unpatched systems faster than many organizations fix them. Three things usually make A.8.8 hard. The asset inventory is incomplete, so some systems are never scanned. Ownership is unclear, so nobody is accountable for fixing a finding in a particular service. And scanners report faster than teams can triage, which produces backlogs that look like neglect. Before committing budget, confirm which of these your environment has, because each one points to a different first fix.

Which systems, teams and suppliers fall under A.8.8

A.8.8 applies to every information system the organization uses, so the first work is deciding which systems, software and suppliers belong in the vulnerability process. Each card below is a scoping decision that changes how much monitoring, patching and supplier follow-up the control requires, and the final boundary must match the ISMS scope and the asset inventory.

Operating systems and endpoints

Every operating system on laptops, workstations, mobile devices and servers needs a named owner, a current software inventory and a route for vendor security updates. Check whether personal devices used for work are in scope, and who receives vulnerability information when an endpoint is off the corporate network for long periods. Ask whether patch status is reported per device or only per fleet, because an auditor will sample individual assets.

Server and cloud workloads

Virtual machines, containers, managed databases and images in cloud accounts often change faster than the asset register. Decide whether ephemeral instances and base images are in scope, and who patches them: the organization, the cloud provider under a shared responsibility model, or a platform team. Confirm that scans cover both running hosts and the golden images they are built from, so a flaw is not reintroduced by the next deployment.

Internally developed and third-party software

Vulnerabilities in code the organization writes, in commercial products it buys and in open-source libraries it bundles each need a different response path. Record every component with its version, including transitive dependencies inside containers. Confirm who triages advisories for each class, since a vendor patch, a library upgrade and an in-house fix follow different timelines and evidence trails.

Network devices and security appliances

Firewalls, routers, load balancers, VPN gateways and wireless controllers often run firmware that receives security fixes on a vendor schedule and is rarely included in endpoint scanning. Decide whether these devices appear in the same register as servers, and who monitors vendor advisories for them. Check that out-of-support devices are recorded with a documented risk decision, since a scanner may not report on them at all.

Teams that must act on findings

Vulnerability information only reduces risk when someone is accountable for acting on it. Identify the teams responsible for infrastructure, application engineering, cloud platforms, and the owners of business applications, and write down who approves a deferral. Confirm that each team can see the findings for its own assets and that security staff track closure, not just detection.

Suppliers and managed service providers

Outsourced operators, software vendors and managed service providers may hold administrative access to in-scope systems or ship code the organization deploys. Their contracts should state how they notify the organization of vulnerabilities, how fast they supply patches, and what evidence they provide. Confirm that the supplier's own vulnerability handling is covered by the organization's supplier review, and that the ISMS scope names every supplier whose systems are in scope.

How an assessor tests technical vulnerability management

This table sets out how an assessor typically samples and inquires into A.8.8, what evidence the organization should have ready, and where gaps usually appear. Read each row as a test the organization should run on itself before the audit starts. The main takeaway is that an assessor follows one chain from information source to asset, scan, ticket, patch and risk decision, so every link must be provable.

Test area	Evidence requested	Common findings
Vulnerability information sources	Documented list of feeds, advisories and vendor bulletins used, with subscription or access records and the owner of each source	Sources named in policy but never reviewed, no owner, or no coverage of key software such as operating systems and network devices
Asset inventory scanned	Current asset register compared against scanner target lists and agent enrollment reports, with dates of the last reconciliation	Assets missing from scan scope, cloud workloads or containers not inventoried, or scanner targets that no longer match the register
Scan results traced to tickets and patches	Sample of recent scan findings followed to tickets, change records, patch deployment reports and re-scan results	Findings closed without evidence, tickets without a linked finding, or patches recorded as applied but still showing on re-scan
Remediation timeliness	The organization's own remediation timelines by severity, and ageing reports showing open items against those timelines	Timelines defined but not enforced, overdue items without escalation, or severity ratings changed without a recorded reason
Risk acceptance approval	Written risk acceptances with the named approver, rationale, compensating controls and review date	Acceptances approved by someone without authority, expired acceptances still in force, or exceptions handled informally in chat
Interviews and walkthrough	Explanation from the people who triage, patch and approve, checked against the documented process	Staff unable to describe the process, or practice that differs from the written procedure

How to implement vulnerability management step by step

The sequence starts with knowing what you run, then finds out which weaknesses apply to those assets, and ends with decisions that are recorded and can be audited. Each step produces a record an assessor can read without a walkthrough.

Build a current asset inventory
Start with a list of every system in scope: servers, endpoints, network devices, cloud workloads, containers, and the business applications and libraries that run on them. Assign each asset an owner and a criticality rating based on the information it holds and the services it supports. The step is done when the inventory extract can be reconciled against cloud accounts, directory records and procurement records, and an owner has signed off on each line. Without this list, later scanning cannot show what is missing.
Select and register vulnerability information sources
Choose the sources that will tell you about technical vulnerabilities in your software and hardware, such as vendor security advisories, national vulnerability databases, distribution security feeds and any sector or national computer emergency response team notices that apply to you. Record each source in a source register with its owner, the products it covers, how it is consumed and how often it is checked. Confirm the licensing and update mechanism for each feed in your own environment, especially for offline networks. The register is the evidence that information gathering is deliberate rather than ad hoc.
Run scanning and software inventory collection
Deploy authenticated scanning and endpoint software inventory so that installed packages and versions are compared against known vulnerabilities for each asset. Open-source options include Wazuh vulnerability detection, which correlates agent inventories with a vulnerability repository that can be hosted offline, Fleet, which matches installed software against several vulnerability sources, and Greenbone Community Edition for network scanning. Confirm which data sources each tool uses and how it handles assets that cannot be scanned. The output is a findings export per scan, plus a record of scan coverage showing which assets were not reached and why.
Consolidate, deduplicate and triage findings
Bring findings from all tools into one place so that the same weakness reported twice is handled once. DefectDojo can import reports from many scanner formats and deduplicate them, which helps teams avoid conflicting records. Triage each finding by asset criticality, whether the weakness is reachable, whether it is known to be exploited, and which owner must act. Write the triage procedure down, including who can downgrade a finding and what evidence is needed. The output is a triaged backlog in which every item has an owner and a documented priority.
Set patch timelines and route changes through control
Define target remediation windows by priority level and document them in the vulnerability management procedure, using timelines that your own risk appetite and contractual obligations support. Route each fix through configuration management (A.8.9) so that the change is recorded against a known baseline, and through change management (A.8.32) so that testing, approval and rollback planning are documented before deployment. Track whether each fix meets its window. The output is a remediation tracker that shows the status, the change reference and the verification scan for each finding.
Record risk acceptance decisions
Where a fix is not possible within the window, such as a vendor has no patch or the system is end of life, record a risk acceptance in the risk register. The entry should name the vulnerability, the affected assets, the compensating controls, the accepting manager, a review date and the conditions under which the acceptance ends. Do not accept risk without a named authority in the organization. The output is a risk register entry per exception, reviewed at the set interval, which lets an assessor see that residual exposure was a decision and not an oversight.
Open an intake route for coordinated disclosure
Publish a way for external researchers, customers and partners to report vulnerabilities in your products or services, along with a process for acknowledging, validating and routing those reports. Connect the intake to the same triage procedure and risk register so that externally reported issues are tracked like internal findings. Confirm the legal and contractual terms you want to offer reporters in your own context. The step is complete when a test report can be traced from intake through triage to a fix or a documented decision.

Evidence that passes an A.8.8 review

An auditor testing A.8.8 wants to see that the organization knows what it runs, learns about weaknesses in those systems, decides what to do and follows through. The artifacts below connect those steps, and each one needs to be refreshed on a schedule so the record shows the process working across the audit period rather than a single scan.

Asset inventory with owners

Every information system in scope needs a current list of software, operating systems and versions, each tied to a named owner who answers for patching and risk decisions. Vulnerability work starts here, because a finding cannot be assessed against a system nobody has recorded. Check that the inventory covers cloud workloads, containers and endpoints, not only data center servers. Keep it current with a recurring export from your discovery or agent tooling, saved as a dated snapshot each month so changes can be traced.

Source register for vulnerability information

A.8.8 asks how the organization obtains information about technical vulnerabilities, so assessors look for a written register of sources. List vendor advisories, national vulnerability databases, distribution security feeds and any threat intelligence feeds, with the owner of each source and how often it is checked. Review the register at least once a year and record the date of each review. An unlisted source that produced a missed patch is a common audit finding.

Scan schedules and result exports

Scheduled scan configurations and their exported results show that vulnerability checks run on a defined cadence and cover the asset inventory. Keep the schedule definitions, the target lists and dated exports of each run, so the auditor can compare results across time. Confirm that scan scope matches the inventory, and document any asset that a scanner could not reach and how it was checked instead. Gaps between scope and inventory are where assessors dig deeper.

Ticket trails from finding to fix

A ticket trail links a specific finding to the asset, the assigned owner, the priority, the change that fixed it and the date of closure. This is the strongest evidence that the process works, since it shows findings moving through a workflow rather than sitting in a report. Deduplicate findings so the same issue is not counted repeatedly, and record why any finding was closed without a fix. Export the tickets periodically so the trail survives tool changes.

Patch timeline records

Patch timeline records show how long fixes took against the timelines the organization set for each severity or exposure level. Keep the defined timelines in a policy or standard, then record deployment dates per asset so the actual performance can be compared with them. Where a patch was delayed, the record should show the reason and the approver. Assessors usually sample a few high-severity items, so make sure those records are easy to pull.

Signed risk acceptances

When a fix is not possible or not yet safe to apply, the organization needs a signed risk acceptance that names the vulnerability, the affected system, the compensating measures, the accountable approver and a review date. Without these, an open finding looks like neglect rather than a managed decision. Set reminders for each review date and keep superseded acceptances rather than deleting them. Confirm with your own risk owners who is authorized to sign for each class of system.

Setting patch timelines and risk acceptance an auditor will accept

A.8.8 does not prescribe a fixed patch deadline. The organization decides how fast each class of vulnerability must be addressed, based on severity, how exposed the affected asset is, and what its loss of availability or integrity would do to the business. What an assessor tests is whether those timelines are written down, approved by the right people, applied consistently and reviewed when they fail. A timeline that exists only in someone's head will not survive sampling. Confirm with your own risk owners how severity is scored (for example, whether you use a vendor score, a exploitability signal or your own rating), and record which asset tiers and exposure conditions move a finding into a shorter window. Pull a sample of closed findings from the last reporting period and check that each one met the documented window or has a recorded reason why it did not.

A missed deadline and a risk acceptance are different things in evidence terms. A missed deadline is a nonconformity with your own rule: the finding was open past its window and nobody formally decided anything. A risk acceptance is a deliberate decision to leave a finding open, and it is only defensible when it is written before the window closes or as soon as the exception is recognized. An approver should record the finding identifier, the affected asset and its owner, the reason a fix is not possible now (such as a vendor patch not yet released or a dependency that would break a critical process), the compensating measures and their owner, the exact expiry date, and the named individual who accepted the residual risk. Expired acceptances should trigger re-review automatically. Vulnerability trackers such as DefectDojo can hold this status and the approval trail, but confirm the workflow before you rely on it for evidence.

Coordinated disclosure intake from external researchers belongs in the same triage path, not in a separate inbox that nobody reconciles. A report that arrives through a security contact or vulnerability disclosure policy should be logged as a finding, matched to the asset inventory, scored with the same method and assigned an owner and a window like any scanner result. Keep the researcher correspondence and the internal decision together so the record shows when the report was received, how it was validated, when it was fixed and whether the reporter was informed. Where a finding is out of scope for your product or already fixed, record that conclusion with the same discipline. An auditor will sample these reports alongside scanner output, so the two sources should look identical in your records.

Cost components of technical vulnerability management

This table lists the cost components behind A.8.8, who is paid for each one, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request and to see which costs self-hosted open-source tooling reduces and which remain with people and processes. No figures are shown because none are supplied for these components; ask each provider for the basis of their numbers.

Cost component	One-time or recurring	What drives it up or down	How to keep it down
Scanning and vulnerability platform licenses	Recurring	Number of assets scanned, number of users, and whether the product is commercial or open source. Self-hosted open-source platforms such as Wazuh, Fleet, DefectDojo and Greenbone Community Edition carry no license fee, though hosting and support still cost money.	Confirm which components are open source and which are paid add-ons, such as vendor feeds, support tiers or hosted services. Ask the implementer to price hosting and upkeep separately from software.
Inventory and asset tagging effort	One-time setup, then recurring upkeep	Size of the estate, how many cloud accounts and sites exist, and how often assets change. Agent-based inventory reduces manual work but still needs owner and criticality tags.	Automate discovery from agents and cloud APIs. Assign an owner and criticality value to each asset at onboarding so later reviews do not rebuild the list.
Engineering time for patching and triage	Recurring	Volume of findings, duplication across tools, number of teams that own systems, and how many patches need testing or downtime windows. Triage is usually the largest internal effort.	Deduplicate findings in one place, set remediation timelines by severity and asset criticality, and batch patches into standard maintenance windows.
Evidence upkeep	Recurring	How many records the assessor expects for each scan, decision and patch, and whether they are kept in a system of record or assembled by hand before each audit.	Store scan reports, tickets and approvals in the tooling itself. Agree the evidence list with the certification body before the audit so collection is not repeated.
External scanning or penetration testing	Recurring, often per engagement	Scope of external attack surface, depth of testing, frequency, and whether retesting after remediation is included. Fixed-scope engagements are priced from written scope.	Define scope in writing, align test dates with major changes, and ask for a retest allowance in the same quote instead of buying it later.
Risk review time	Recurring	Number of accepted risks, how many require approval from senior management, and how often acceptances are reviewed. Unreviewed acceptances tend to accumulate.	Keep a single register of accepted risks with an owner, a reason and a review date. Limit who can approve acceptances.
Auditor sampling	Recurring, per audit cycle	Number of in-scope assets and findings the auditor samples, and how easily the evidence can be retrieved. Gaps found in sampling often lead to extra audit days or nonconformities.	Run a readiness review of sample evidence before the audit. Ask the certification body how it plans sampling and what it needs in advance.
Implementation partner scope	One-time, with optional retainer	Whether the partner deploys and configures tooling, builds dashboards and documents procedures, or only advises. Ongoing upgrades and continuous testing are separate retainers.	Request a fixed-scope written proposal listing deliverables, handover items and what the organization must run itself. Ask which items are one-time and which need a retainer.

Who does what: your team, a partner and the auditor

Your organization owns A.8.8. Accountability for obtaining vulnerability information, assessing exposure and acting on it stays with named internal roles, usually security operations, the platform or infrastructure team and the owners of each application. An outside partner can build the tooling, but it cannot decide which risks you accept or which patch deadlines apply to your business.

Policy and risk decisions: Define the vulnerability handling policy, severity thresholds, patch timelines by asset criticality and the approval path for risk acceptance.
Asset inventory ownership: Keep the list of systems in scope current, since vulnerability tracking is only as complete as the asset records behind it.
Triage and remediation: Assign findings to system owners, track fixes to closure and record exceptions with a reason and an expiry date.
Ongoing operation: Review scanner coverage, false positives and overdue findings on a set cadence, and keep the records that show this happened.
Vendor and advisory monitoring: Decide how you receive information about vulnerabilities in the products you use and who reads it.

Before engaging anyone, confirm which of these roles already have named owners and written procedures, because an auditor will ask for both.

Common gaps that fail A.8.8 and how to close them

Most A.8.8 findings trace back to a few gaps in the basic chain: knowing what you run, scanning all of it, assigning owners, tracking timelines and governing exceptions. The cards below pair each gap with the fix an assessor will expect to see as evidence.

No current asset inventory

Vulnerability work starts with knowing which systems, applications and components exist. Without an inventory that is kept current, scans miss hosts and no one can say whether a published advisory affects the estate. Build the inventory from cloud accounts, network discovery and endpoint agents, then reconcile the three sources on a fixed schedule. Check that every asset has an owner and a criticality rating.

Scans that cover only some hosts

A scanner that reaches 80 percent of the estate gives a false sense of coverage, and the unscanned hosts are often the ones nobody remembers. Compare scanner target lists against the asset inventory and count the gap. Confirm that new hosts are added to scan scope automatically, and that authenticated scans run where the platform allows them, since they report far more installed software than unauthenticated probes.

Findings with no owner

A finding that sits in a queue without a named team is effectively unmanaged, and assessors look for the path from detection to a responsible person. Route each finding to the team that owns the affected asset, using ownership data from the inventory. Deduplicate findings across tools so one flaw is not assigned three times. Review unowned items in a recurring meeting and record the decision.

Patch timelines not tracked

Many organizations write patch timelines into policy but never measure whether they are met. Set deadlines by severity and asset criticality, store the due date with each finding, and report overdue items to the owner and to management. Keep the change record linked to each fix so the auditor can trace a finding from detection to closure, including the change control that applied the patch.

Risk acceptances without approval or expiry

Some vulnerabilities cannot be fixed on time, for example when a vendor has no patch. These exceptions need a documented rationale, compensating controls, a named approver with authority over the risk, and an expiry date that forces re-review. Undated acceptances quietly become permanent. Confirm that every open overdue finding either has an approved acceptance or appears in the risk register.

No record of external vulnerability reports

Reports from researchers, customers, vendors or national CERTs reach the organization through email, forms or bug bounty channels, and many are handled informally. Define a single intake point, a triage procedure, a response owner and a disclosure approach, then log each report with its outcome. Confirm the procedure is tested, since an assessor will ask for a sample of real reports and how each was resolved.

How A.8.8 relates to NIST and NIS2 controls

Two published mappings connect A.8.8 Management of technical vulnerabilities to controls outside ISO/IEC 27001, and both are useful starting points for a multi-framework program. The first is NIST's crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022, posted to the OLIR catalog in November 2023. It relates A.8.8 to RA-3 (Risk Assessment), RA-5 (Vulnerability Monitoring and Scanning), SI-2 (Flaw Remediation) and SI-5 (Security Alerts, Advisories, and Directives). In practice, RA-3 and RA-5 correspond to the identification and assessment steps, SI-2 to patch and remediation timelines, and SI-5 to how advisories reach the people who act on them. NIST cautions that mapped controls are not always equivalent, so a passing A.8.8 review does not automatically satisfy RA-5 in full, and the gaps usually sit in scan depth, scan frequency and remediation evidence.

The second mapping is ENISA's table for its NIS2 technical implementation guidance, version 1.2 from August 2025. It links A.8.8 to point 6.10 of the Annex to Commission Implementing Regulation (EU) 2024/2690, which covers vulnerability handling and disclosure. Organizations in scope of NIS2 should read point 6.10 directly, because it addresses handling and disclosure processes that go beyond identifying and patching vulnerabilities, including how reports from outside the organization are received and processed. Confirm which of those elements your own process covers before you list A.8.8 as the evidence for them.

Treat both tables as pointers, not proof. Open the NIST crosswalk and the ENISA spreadsheet, compare each mapped requirement with the wording of the control or point you rely on, and record any difference in your Statement of Applicability or compliance matrix. An assessor will test your own evidence, such as scan records, remediation tickets and disclosure procedures, against the requirement, not against a mapping table. Where a mapping suggests coverage you cannot demonstrate, plan the missing evidence before the assessment.

Questions buyers ask about A.8.8 cost, time and ownership

How much effort does meeting A.8.8 take?

Effort depends mostly on how many systems you run, how many of them are in scope for the ISMS, and how mature your vulnerability handling already is. A.8.8 has no fixed effort figure, so the honest starting point is an inventory of assets and software. Organizations with a current asset register, scheduled scanning and a patch routine usually spend their effort on documenting decisions and evidence. Organizations without those basics spend most of their effort building them. Ask any provider to break the estimate into inventory, scanning setup, triage workflow, patch timelines, risk acceptance records and evidence collection, with the hours or days attached to each.

How long does it take to get A.8.8 evidence in order?

The duration depends on your starting point, but the evidence an auditor reviews is produced over time, not in a single sprint. Certification bodies run a three-year certification cycle with at least one audit, either surveillance or recertification, in every calendar year (European Accreditation FAQs 51.7 and 37.12). That means vulnerability records need to show a working process across many months before the first audit. Ask for a plan that sets out when scans start, how long the first full cycle of triage and patching runs, and when the first set of risk acceptance decisions will exist.

Can a small team run A.8.8 in-house?

Yes, a small team can run A.8.8 in-house if the scope is kept tight and the tooling is simple. The control asks for a repeatable way to learn about vulnerabilities, judge exposure and act, so the minimum is an owner, an asset list, a scanning schedule and a short patch policy with timelines. Open-source tools such as Greenbone Community Edition or Wazuh can produce scan and detection results, but someone still has to review them every cycle. Small teams usually struggle with triage volume and with keeping the asset inventory current, so plan that time explicitly.

What does A.8.8 need from our own staff?

A.8.8 needs named owners who make decisions the organization cannot outsource. The work includes maintaining the asset inventory, deciding which vulnerabilities matter for each system, approving patch timelines, signing off risk acceptances and reviewing exceptions. System administrators carry out patching, application owners confirm business impact, and security staff review trends and reports. Management should approve the policy and accept residual risk. Ask any partner to show which role signs each decision, because an auditor will ask who made each call and when.

Can an implementation partner replace our internal ownership of A.8.8?

No. An implementation partner can design the process, configure scanners and inventory tools, and prepare evidence, but the organization must own the control and its decisions. Only an independent auditor or certification body can assess conformity and issue a certificate. The partner's role is preparation, and its deliverables should be written into a fixed-scope agreement with named outputs, such as configured tooling, a documented triage workflow and an evidence pack. After handover, your staff must run the process, because the auditor will test whether it operates in practice, not whether a consultant set it up.

What should we ask for in a quote for A.8.8 work?

A useful quote lists scope and deliverables before any price. Ask for the systems and asset classes included, the tools to be deployed or integrated, the workflow documents to be written, and the evidence to be handed over. Also ask which costs recur, such as scanner licensing if you use a commercial product, staff time for triage each cycle, and any retainer for ongoing support or upgrades. DeployOpen works from a written scope and does not publish a price list, so ask for a quote that follows from that scope and separates one-time setup from ongoing operation.

What drives A.8.8 cost up or down?

The main drivers are the number of assets, the variety of operating systems and applications, the state of existing inventory and tooling, and how many approvals the workflow requires. Costs go up when inventory is missing, when many environments such as cloud, on-premises and air-gapped networks need separate scanning, and when patching must follow strict change windows. Costs go down when asset data is already accurate, scanning is centralized and risk decisions follow a clear template. Ask a provider which of these factors its quote assumes, so you can see what changes if your environment differs.

How DeployOpen scopes and prepares A.8.8 evidence

DeployOpen plans and deploys self-hosted open-source vulnerability tooling inside your own infrastructure, so that asset inventory, scanning, findings and remediation records exist as evidence before an assessor asks for them. The organization keeps ownership of its risk decisions and control statements, while DeployOpen prepares the systems and records that support them.

How we scope

The written scope lists which systems, endpoints and networks feed vulnerability tracking for A.8.8.
Scope also names the sources of vulnerability information and who reviews findings and approves risk acceptance.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Endpoint software inventory and vulnerability detection are deployed in your environment, such as Wazuh or Fleet, for in-scope hosts.
Scanning with Greenbone Community Edition and findings consolidation in DefectDojo are configured to your scan schedule and asset list.
Each tool is tested against a known test host so you can confirm that detection and deduplication behave as documented.

How we hand over

You receive configuration records, asset inventory exports and a documented triage and patch timeline procedure.
Handover includes a runbook for risk acceptance entries, exception review and evidence collection for each review cycle.
Final evidence is reviewed with your team, and the independent auditor decides whether it satisfies A.8.8.

How we support

Ongoing support, tool upgrades and continuous testing are available as retainers after handover.
Retainers can cover tuning of scan coverage, updating feeds and reviewing new findings against the asset register.
Confirm with us in the written scope which tool versions, update cadence and response windows apply to your engagement.