A.8.34 audit testing protection: requirements and evidence

What A.8.34 audit testing protection asks of live systems

Control A.8.34 asks that audit tests and other assurance activities that assess operational systems are planned and agreed between the tester and the appropriate management before they run. If an auditor, penetration tester or assessor is about to examine systems that carry live business processes, the organization should be able to show who approved the test, what it covers, and when it happens. The risk is concrete: a scan that saturates a fragile application server, a credential test that locks out a production service account, or a data extraction that exposes personal information can disrupt operations or create a security incident of its own. Tests run without authority are also a governance failure, because the people accountable for the system did not decide whether the risk was acceptable.

The difficulty is that testing and operations pull in different directions. Assessors want realistic conditions and minimal warning, while operations teams want predictable change windows and no surprises. The control does not settle that tension for you. It expects the agreement to be recorded, not assumed. In practice, the organization should confirm that each test has a named approver from management, a written scope that lists systems, source addresses, permitted techniques and prohibited actions, a time window, a rollback or stop procedure, and a named contact on both sides who can halt activity. Ask whether those records exist for your last audit and penetration test, and whether they match what the testers actually did.

The 2013 edition traced this requirement to A.12.7.1 Information systems audit controls, and the correspondence table in ISO/IEC 27002:2022 Annex B shows that link. A.5.35 Independent review of information security and A.8.8 Management of technical vulnerabilities are closely related, since independent reviews and vulnerability testing are common sources of these activities, but they are not the same requirement. A.8.34 concerns how the testing is governed and protected, so treat it as a separate check. The ISO/IEC 27002:2022 page is the natural next read for the guidance behind the control.

Which systems, testers and teams fall under A.8.34

A.8.34 applies whenever someone tests operational systems for assurance, and the scope decisions below determine how much of that testing can run live and who must agree first. Each card names one decision and what it changes, so the tester and management can settle the plan before any traffic is sent.

Live production versus staging copy

The first decision is whether a test can run against the live operational system or only against a staging copy. Live testing carries the risk of disrupting business processes, so the plan should state which checks touch production, which rate limits apply and when they run. Anything that can change data or availability usually moves to a staging copy. Confirm that the copy matches production configuration closely enough for the results to mean something.

Internal audit and assurance reviews

Internal audit reviews often involve reading configurations, sampling logs and checking access lists rather than sending attack traffic. These activities still touch operational systems, so the audit plan should list the systems, accounts and times involved. Agree in advance who may run queries against production databases and which audit tools may connect to live hosts.

External certification auditors

A certification body samples evidence and may request system walkthroughs, but it does not normally send test traffic. Its needs are access to records and interviews, which should be arranged so that auditors observe systems without changing them. The organization decides who accompanies auditors into sensitive environments and which screen-sharing or remote sessions are permitted.

Penetration testers and red teams

Penetration tests send active exploit attempts, so they carry the highest disruption risk among tester types. The engagement letter should define permitted techniques, testing windows, stop conditions and the named contacts who can halt the work. Testers should not exceed the agreed scope even when they find a path further into the environment.

Vulnerability scanning jobs

Authenticated and unauthenticated scans can slow fragile legacy hosts, trigger intrusion alerts and lock accounts after repeated login attempts. Scan schedules, source addresses, throttling settings and exclusion lists should be agreed with system owners before the first run. Keep the scan credentials scoped to what the scan needs, and record when scans run so that monitoring teams can separate them from real attacks.

Customer auditors and third-party hosted systems

Customer audits and hosted platforms bring a second layer of permission. A cloud or SaaS provider's terms may prohibit or restrict testing of its shared infrastructure, and a customer auditor may ask for access that the organization cannot grant alone. Check provider contracts and acceptable-use policies first, then agree any joint testing with the provider and the business owner who signs for the system.

Business and system owner approval

Before any test starts, the business owner who accepts the operational risk and the system owner who runs the platform should both approve the plan in writing. The business owner decides whether a disruption window is acceptable, while the system owner confirms backups, rollback steps and on-call cover. Record these approvals as evidence, because an assessor will look for them when testing against A.8.34.

How an assessor tests the planning and agreement of audit tests

This table compares what an assessor asks at each stage of an audit test on operational systems, from planning through closure, with the evidence usually requested and the findings that commonly appear. Read each row as a question to answer before testing starts, not after. The main takeaway is that a test with no written agreement, no defined scope and no monitoring is hard to defend, even when it found nothing.

Stage	Question the assessor asks	Evidence requested	Common findings
Planning	Is there a documented plan for each test or assurance activity on operational systems, with its objective and the systems in scope?	Approved test plans, scope documents naming systems, addresses and accounts, and the test objective for each activity	Test plans are missing, generic, or do not name the systems actually touched
Planning	Were the risks to business processes considered before testing, such as outages, data exposure or load on production?	Risk or impact notes attached to the plan, and a list of business processes that could be affected	No impact assessment, or the assessment ignores batch jobs, backups and peak periods
Agreement	Did the appropriate management owner approve the test, and is that approval recorded before work starts?	Signed or recorded approvals from the system owner and a manager with authority over the business process, dated before the test window	Tests run on verbal agreement, approvals dated after the test, or approval given by someone without authority over the system
Agreement	Are the rules of engagement, including permitted techniques, forbidden actions and escalation contacts, agreed in writing?	Rules of engagement document, contact list for escalation, and confirmation that the tester received them	Rules are absent or unclear about denial-of-service or data extraction, and no escalation path is named
Execution controls	Was the test confined to the agreed systems and time window, and were changes recorded through the normal process?	Change or ticket records for the test window, access logs for the tester accounts, and scope confirmation during the test	Out-of-scope systems touched, test activity outside the window, or no ticket linking the test to a change record
Execution controls	Was the operational system monitored during the test, and could the team stop the test quickly?	Monitoring dashboards or logs covering the test period, on-call records, and a recorded stop or pause procedure	No monitoring during the test, or no one watching the system when the test ran, so impact went unnoticed
Closure	Were the results reported to the agreed owners, and were test accounts, temporary access and test data removed?	Test report with date and scope, record of removed accounts and access, and evidence that findings entered the remediation process	Test accounts left active, findings not tracked to closure, or no report delivered to the system owner

Implementing A.8.34 step by step

This sequence turns audit testing on operational systems from an informal request into an agreed, approved and recorded activity, so that assessors can test controls without disrupting business processes.

Define which activities count as audit testing
Start by listing every activity that will assess operational systems during an audit or assurance cycle, including internal audit tests, external assessor scans, penetration tests, configuration reviews and sample-based checks of access or logs. The control owner and the audit lead agree the list and mark which activities touch production. The output is a scoped inventory of assurance activities, and the step is done when each item has a named requester, a target system and a flag for production impact.
Assign approvers and their responsibilities
Name the people who can approve a test on each class of system, usually the system owner for the application, the operations lead for infrastructure and a security or risk manager who holds the decision for production. Record who can approve, who must be consulted and who is informed, and confirm that the tester knows the approval route. The output is a short approval matrix, and the step is complete when every activity from the inventory maps to at least one accountable approver.
Draft a standard rules-of-engagement template
Write one reusable template that the tester and management sign before any test starts. It should state the scope in terms of systems and addresses, the source IP addresses the tester will use, the permitted test windows, prohibited actions such as denial-of-service or data exfiltration, rules for handling any personal or confidential data encountered, the named contacts for each side, and a stop condition that either party can invoke. The output is a template with version control, and the step is done when legal, security and operations have each reviewed it once.
Run a pre-test review for production systems
Before any test touches an operational system, hold a short review with the approver, the tester and the owner of the affected service. The group checks backup status, monitoring coverage, change freezes, dependencies on the target and whether a safer environment could give the same assurance. Any conditions agreed in the review are written into the rules of engagement. The output is a review note, and the step is done when the approver has signed the conditions or documented why none are needed.
Record approvals in the ticketing or change process
Log each approved test as a ticket or change record in the system the organization already uses for requests, so that the approval, rules of engagement, test window and named contacts sit together. Tools such as GLPI or Zammad can hold this workflow if the organization runs them, but the platform matters less than consistent use. The output is an approval log with a unique reference per test, and the step is done when operations can see every test scheduled against production.
Publish and maintain the test calendar
Build a shared calendar of approved test windows across systems and teams, so that operations can avoid overlapping changes, maintenance and other tests. Update it whenever a window moves or a test is cancelled, and tie each entry to its approval record. The output is a living test calendar, and the step is complete when the operations lead confirms that the calendar is the reference used for change scheduling.
Execute within the agreed boundaries and stop when required
During the test, the tester works only within the sources, windows and prohibited actions in the signed template. The named contact watches for service impact, and either party can invoke the stop condition immediately. Any incident caused or discovered during the test is handled through the normal incident process and recorded against the test reference. The output is a test log with timestamps, and the step is done when the log shows the test ended within bounds or that the stop condition was used and recorded.
Close each test with a report and lessons learned
After the test, the tester issues a report that covers the findings, the systems touched, any data accessed and any deviations from the rules of engagement. Management reviews it, decides on remediation owners and records lessons about scope, timing and communication for future tests. The output is a closure record linked to the approval log, and the step is complete when every finding has an owner and the closure record is filed with the audit evidence.

Writing rules of engagement that protect operations

A usable agreement between the tester and management turns a general permission into a set of decisions both sides can check. It should name the systems in scope and the ones explicitly excluded, the test windows, the source addresses the tester will use, the techniques allowed and forbidden, the rate limits on scanning and load, the data the tester may touch, and how findings and evidence are handled. Agreements fail at audit when they only say that testing will happen. An assessor asking how the organization decided a test would not disrupt business processes will look for a dated, signed record of those specifics, not for a sentence saying the parties agreed in principle. Agreeing a test in principle is not the same as agreeing its exact scope, timing, rate limits and escalation path. The first lets work begin; the second is what protects a production order-processing service at 2 p.m. on a Tuesday.

Escalation is where many agreements are weakest. The document should name, by role and by a reachable contact, who may pause or halt the test, the conditions that trigger a halt (for example, latency or error thresholds agreed in advance), who is told, and how quickly the tester must stop and confirm. Illustrative example: a scan that begins triggering a payment provider's fraud controls should have a named operations owner who can stop it without waiting for the tester to finish a run. Check the contractual side too. Scanning vendors, cloud providers and hosted SaaS providers can impose their own notice periods, permitted-testing rules or approval steps for testing their services, so confirm each one before the window is set. The provider terms and each supplier's own published testing policy are the places to start, and the agreement should record which of them were checked.

Evidence that satisfies A.8.34 and how to keep it current

An assessor testing A.8.34 looks for a paper trail that starts before any test and ends after it. The artifacts below connect the planning, approval, execution and closure of each assurance activity on operational systems. Keeping them versioned and tied to the test calendar is what lets the evidence still describe the systems as they are at the next audit.

Test plan or statement of work

The test plan states the objective, the techniques, the systems in scope, the people performing the work and the expected impact on operations. For A.8.34 it is the document management agrees to before any tester touches an operational system. Check that it names the tester, the testing period and the disruption you will accept. Store each version in a repository with a change history, and reissue it whenever the scope changes between test cycles.

Signed rules of engagement

Rules of engagement record the permitted techniques, forbidden actions, escalation contacts and the conditions under which testing must halt. They are the clearest proof that tester and management agreed the limits in advance. Confirm that the signatories have authority over the systems concerned, not only over the testing budget. Keep signed copies alongside the test plan and review the rules at each test cycle, since the set of permitted techniques often changes.

Scope and asset list

The asset list shows which hosts, applications, network segments and data stores fall inside the test, and which are excluded because they are production-critical or shared with third parties. An assessor compares this list with what the organization actually runs, so drift matters. Generate it from your configuration or inventory records where possible, and tie each entry to an owner. Recheck it against the current inventory before every test window.

Approval record

The approval record shows who authorized the test and when, usually from a change or ticket workflow. It should reference the test plan version and the rules of engagement version that were approved. Use a ticketing or change tool so approvals are timestamped and cannot be silently edited. Review the approver list at each cycle, because staff changes can leave a test authorized by someone who no longer owns the system.

Test window calendar

The calendar records when each assurance activity runs, which systems are affected and which business processes must stay available during the window. It shows that testing was scheduled around operations rather than against them. Keep it in a shared calendar or helpdesk planning view linked to change records. Update it whenever a window moves, and check it against business peaks such as month-end processing before each cycle.

Monitoring and stop-condition log

During execution, the tester and the operations team should log monitoring data, observed impact and any stop condition that was triggered. This record proves that management could see the test's effect on live systems and could halt it. Define stop conditions in advance, such as service degradation thresholds or unexpected data access. Keep logs from the monitoring platform and link them to the ticket for that window.

Closure report

The closure report summarizes what was tested, the findings, any incidents caused by testing, and the remediation tickets raised. It closes the loop that A.8.34 expects, because it shows that the assurance activity ended cleanly and its results went to the people responsible. Store it with the earlier artifacts so one folder tells the full story. Confirm that findings link to tracked remediation items, and carry open items into the next cycle's test plan.

What meeting A.8.34 costs in money and effort

This table lists each cost component of planning and running audit tests on operational systems, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for quote, since no price is published here and the real figures depend on your own systems and test plan.

Cost component	Who carries the cost	One-time or recurring	What drives it up or down
Test planning and rules of engagement	System owner, security lead and tester time	One-time per test cycle, repeats with each new test	Number of operational systems in scope and how many test windows must be agreed with management
Ticketing and approval tooling	Organization, through licenses or self-hosting effort	Recurring if licensed, one-time setup if self-hosted	Number of approvers and requesters; self-hosted options such as GLPI or Zammad can remove license spend but add hosting and upkeep
Engineering time for monitoring during tests	Platform and operations engineers	Recurring for each test window	Number of systems under live monitoring, test frequency and how much alerting must be tuned to avoid disruption
Evidence upkeep	Compliance lead and system owners	Recurring through the audit cycle	Volume of test records, approvals and log extracts retained, and how well they are stored and indexed from the start
External tester fees, if a partner runs tests	Organization, paid to the testing firm	Usually per fixed-scope engagement, with retainers for continuous testing	Number of systems and applications, number of testers, depth of testing and whether testing is one-off or continuous
Auditor sampling time	Organization, paid to the independent auditor	Recurring with each audit cycle	Number of test records the auditor samples and how easily the organization can produce them without rework
Remediation of issues found during tests	Engineering and system owners	Variable, recurs when tests find issues	Quality of the test scope, prior hardening and how quickly findings are triaged and fixed

Open-source ticketing tools that can hold A.8.34 approvals

Audit tests on operational systems need a written request, an agreed window, named approvers and a closure record. Ticketing tools are a practical place to keep that trail, but neither product ships with an audit-test workflow, so the approval steps must be configured and confirmed before they are relied on.

GLPI as the change and approval record

GLPI's Assistance module creates tickets, problems and changes that follow ITIL practices, with plannings, statistics and a Kanban view. For A.8.34, a change type can represent a test request, with fields for the target system, test window, tester and the business owner who agrees to it. Confirm that its change approval steps can require sign-off from the system owner and the security lead before the test window opens, and that closure captures the test outcome and any disruption. Check whether the planning view can block overlapping production changes.

Zammad as the request intake

Zammad is a web-based helpdesk that brings email, chat, telephone and social media messages into one ticket system. It suits the intake side of A.8.34, where a tester, a business unit or an external assessor sends a request that needs a recorded decision. Confirm that its states and approval fields can reflect planned, agreed, executing and closed test stages, and that restricted groups can see requests on sensitive systems. Check whether it can hold the approver's written agreement as an attachment or linked record.

GPL-3.0-or-later obligations

GLPI is licensed under GPL-3.0-or-later. Organizations that only run it internally usually face few distribution duties, but any modified version they give to others, including a contractor, may trigger source disclosure under the license. Ask the implementation partner to document every change to the code, keep customizations in plugins where possible, and have legal review the arrangement before the tool is extended for assessment work.

AGPL-3.0-only obligations

Zammad is licensed under AGPL-3.0-only, and the network clause of that license can apply when a modified Zammad is offered to users over a network. If an assessor, customer or contractor interacts with a hosted, changed instance, the source of that instance may need to be offered. Record every modification, confirm with counsel whether the deployment triggers the obligation, and keep any changes limited to configuration where that is enough.

Fields that prove the test was agreed

Whichever tool is chosen, the ticket must hold more than a status. Record the systems in scope, the tests planned, the agreed window, the named approver and the date of agreement, plus rollback and stop conditions. Closure should attach the test report location and any incidents caused. Confirm whether the tool can enforce mandatory fields before a ticket moves to the executing state, because an auditor will look for gaps between agreement and execution.

Who owns the workflow

The organization owns the approval decision and the rules for who may approve a test on each system. An implementation partner can configure the tool, migrate templates and document the workflow, but cannot approve tests on the client's behalf. Ask for the configuration record, the list of roles and approvers, and a walkthrough of one test ticket from request to closure before the first live test is scheduled.

Who owns A.8.34 and what can be outsourced

Your organization owns A.8.34. It decides which audit tests and assurance activities may touch operational systems, who approves them, and when they run. The control asks that tests are planned and agreed between the tester and appropriate management, so the signed agreement and the approvals sit with you, not with the person running the test. Ownership also means you stay accountable for the business impact if a test degrades a live service.

Agreement and scope: Management approves a written test scope, including target systems, permitted techniques, excluded systems, time windows and stop conditions.
Approvals: Named system owners sign off on tests that touch their platforms before they start.
Test calendar: You maintain one calendar of audit tests, penetration tests and other assurance work so that operations teams know when activity is expected.
Emergency stop: A named contact can halt any test at once, and the tester knows how to reach that person.
Records: You keep the approved scope, sign-offs and calendar entries as evidence that the control operates.

Check that each approved test has a named owner on your side, a documented stop condition and a retained record of the sign-off.

Where organizations fall short on audit test agreements

A.8.34 asks that tests on operational systems are planned and agreed with management before they start. The gaps below are the ones that most often turn an assurance activity into an outage, a dispute or an assessor finding. Each card pairs the gap with a fix the organization can put in place before the next test window.

Tests on production without a recorded agreement

A tester begins scanning or exploiting a live system on the strength of a verbal request or a general engagement letter that never names the system, the window or the approver. When something breaks, nobody can show that management agreed to the activity. Before any test touches an operational system, record a written test plan that names each target, the test window, the source addresses and the manager who approved it. Ask the auditor or tester to confirm that the approval exists before the first packet is sent.

Rules of engagement signed after testing

Rules of engagement set out what the tester may and may not do, including prohibited techniques, data handling and escalation. When they are signed after the work is finished, they describe what already happened rather than what was agreed in advance. Require signed rules of engagement as a gate: no test account, scanner license or network allowlist entry is issued until both parties have signed. Keep the signed copy with the test plan so that an assessor can trace each action to an approved rule.

No named person able to stop a test

When a test degrades a service, the tester often calls a general support inbox and waits. A test with no named stop authority can run for hours while the business suffers. Name one operational contact and one deputy on the business side, with their phone numbers and authority to halt the activity immediately. Confirm the stop procedure in a dry run before testing starts, and record the time each stop was requested and carried out.

Scope drift during execution

Testers follow leads. A finding on one application can lead to a shared database, a neighboring subnet or a third-party service that the agreement never covered. Each step outside the agreed scope can breach contracts or data protection rules, even when the intent is legitimate. Write the scope as a list of named assets and address ranges, require the tester to request a written change before touching anything else, and log every scope change with its approver and the time it was granted.

No monitoring during the test window

If the operations team does not watch the system during the window, it cannot tell a planned test from a real intrusion, and it cannot tell whether the test caused a fault. Assign someone to monitor the affected systems, dashboards and logs for the whole window, and agree in advance how test traffic will be tagged, for example with a known source address or test account name. Keep the monitoring records as evidence that the system was observed and that the test stayed within its agreed limits.

Closure reports missing

A test that ends without a closure report leaves no evidence that the activity was completed, what was found, what was removed and who accepted the results. Test accounts, temporary firewall rules and copied data often stay behind. Require a closure report that lists the activities performed, the systems touched, the findings, the cleanup actions with confirmation, and management's acceptance. Track each finding into the vulnerability or corrective action process so that the report leads to a documented result.

How much effort and cost A.8.34 takes, and whether to do it in-house

What does it cost to meet A.8.34 Protection of information systems during audit testing?

No supplied fact gives a price for A.8.34, and the cost depends on your environment and how much testing your auditors and assurance activities require. The main cost components are internal time from the people who plan tests and approve them, management time for sign-off, and any external testers or assessors you engage. The control itself is mostly a process, so its recurring cost is the effort of planning each test window, agreeing rules of engagement, and keeping records. To get a fair picture, ask any provider for a written scope listing the systems in scope, the test types, the number of test windows per year, and the deliverables. A quote follows from that scope, and DeployOpen does not publish a price list.

What drives the effort of agreeing audit tests on live systems?

The effort rises with the number of operational systems that auditors or testers touch, how sensitive those systems are, and how many parties must approve each test. Systems that support customer transactions or regulated services usually need more careful planning than internal tools. Effort also grows when testing is frequent, when tests cross into third-party hosted services, or when the organization has no standing rules of engagement. Effort falls when systems are well documented, when test windows already exist for change management, and when a single owner can speak for each system. Ask for an estimate that separates one-time setup, such as writing the agreement template, from recurring work, such as scheduling each engagement.

How long does it take to set up the agreement process for audit testing?

The setup time depends on how quickly your organization can agree on who approves tests, which systems are in scope, and what testers may and may not do. The work usually starts with an inventory of operational systems, then a short template for the test plan, the rules of engagement, the communication path, and the rollback or stop conditions. Delays usually come from unclear system ownership, from waiting on several management approvers, or from third parties whose consent is needed. No duration is supplied for this step, so ask any partner to propose a timeline in the written scope after reviewing your systems and approval chain.

Can a small team run A.8.34 without outside help?

Yes, a small team can run A.8.34 in-house if one person owns the process, system owners are identified, and management agrees to a simple approval rule. The control asks for planning and agreement, not specialized tooling, so the main skill is writing clear test plans and recording decisions. Outside help is most useful when the team lacks experience with penetration testing or audit sampling, when the systems are complex, or when auditors expect a more formal record. A small team should still keep a register of approved tests, the approver for each, and the outcome, because that register is the evidence an assessor will ask to see.

What does A.8.34 need from system owners and management?

System owners need to confirm which systems are operational, what could be affected by a test, and when a test window is acceptable. Management needs to approve the scope, the testers, the test types, and the conditions under which testing must stop. In practice, owners review each test plan, identify fragile components and business peak periods, and name a contact who can halt the work. Management sets the policy, decides how risk is accepted, and signs off on exceptions. Without these named roles, tests either wait too long or proceed without the right approval, and both outcomes are hard to explain to an assessor.

Can an implementation partner prepare A.8.34 evidence without issuing a report or certificate?

Yes. An implementation partner such as DeployOpen can help prepare systems, test plans, approval records and evidence for an assessment, but it does not issue audit reports, attestations or certifications. Only an independent auditor, assessor or certification body issues those outcomes. Your organization keeps ownership of its controls and decides which tests are approved. A typical engagement is fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any partner to state in the written scope exactly which artifacts it will produce and confirm that the independent assessor will review them.

How do open-source tools help keep A.8.34 records?

Open-source helpdesk and service management tools can hold the test requests, approvals and outcomes as tickets, which creates a traceable record. For example, GLPI's Assistance module supports tickets, problems and changes following ITIL practices, with plannings and a Kanban view, and Zammad is a web-based helpdesk that gathers customer communication in one ticket system. Either can be self-hosted in your own infrastructure. Confirm that the chosen tool supports the approval workflow, retention and access controls you need before relying on it.

How DeployOpen scopes and prepares A.8.34 evidence

DeployOpen approaches A.8.34 Protection of information systems during audit testing as a planning and evidence task inside the client's own infrastructure. We prepare the systems, agreed test windows and records so that the organization can show its audit and assurance testing was planned, approved and kept from disrupting operations. The organization owns the control and the decisions, and an independent auditor issues any report or certificate.

How we scope

Engagements are fixed-scope, with the A.8.34 boundary, systems and test types agreed in writing before work starts.
The written scope names which operational systems may be assessed, who approves each test, and who from management signs off.
We confirm with you which assurance activities the auditor expects, such as vulnerability scans, penetration tests or log reviews.

How we build

We set up test planning records, rules of engagement and change tickets that capture each agreed audit test before it runs.
We configure a ticketing workflow, for example in GLPI or Zammad, so approvals, schedules and stop conditions are recorded.
We document how test traffic, accounts and timing are isolated from production business processes and monitored during each run.

How we hand over

You receive the test plans, approval records, rules of engagement and a register of executed assurance activities for the auditor.
Runbooks explain how to pause or halt a test, how to confirm normal service afterwards, and who is responsible at each step.
We walk your team through the evidence pack so your staff can explain it to the auditor and keep it current after handover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer for systems that change between audit cycles.
A retainer can refresh test plans and approval templates when systems, owners or assurance requirements change.
Confirm with DeployOpen in the quote which support tasks, response expectations and review points are included in the retainer.