What Article 15 right of access requires from your systems
Article 15 requires a controller to answer a data subject request in three parts: confirm whether personal data about the person are processed, provide a copy of the personal data undergoing processing, and supply supporting information on purposes, categories, recipients, retention, rights, source and automated decision-making. The person does not have to give a reason, and the controller cannot insist on a particular form or channel, although it should offer a user-friendly route. Your systems therefore need to answer three questions quickly: what do we hold about this person, where is it, and what does our record of processing say about it? If a request or an audit is already under way, the first job is to confirm the request was logged and the clock started, then to find out whether your procedure can actually answer those questions.
The hard part is usually the search, not the export. The EDPB's Guidelines 01/2022 expect the controller to search all IT systems and non-IT filing systems, using criteria that match how the data are structured, such as name and customer number. Helpdesk tickets, mailboxes, shared drives, HR and CRM records, backups in active use, and paper files in branch offices all count. Activity logs and records of who searched for the person can also fall within scope, and pseudonymised data remain personal data. Ask your team to produce a current list of systems that hold personal data, and check which of them can be searched by identifier at all. Where a system cannot, that gap belongs in the procedure before a request arrives.
The EDPB's 2024 coordinated action on the right of access, reported in January 2025 across 30 data protection authorities, found that two thirds of authorities rated compliance as average to high. Among the challenges it named were undocumented procedures and excessive identification demands. Both are design problems you can check now: write down the steps and owners for each request type, and set a rule that identity checks use no more personal data than the risk requires, such as matching the account already in use rather than asking for new documents by default. Confirm your own procedure against the EDPB's guidance and your legal counsel's view before you rely on it.
Which systems, teams and processors fall under an access request
An access request reaches every place the controller holds personal data about the requester, including systems outside IT, paper files, copies held by processors and the logs that record how the data were used. The cards below cover the scoping decisions that determine how much work each request creates and who must act on it.
Core business applications
CRM, ERP, billing, HR and support platforms usually hold the bulk of personal data. Map each application to the search keys it uses, such as name, email, customer number or employee ID, because the EDPB expects searches to mirror how the data are structured. Assign an owner per application who can run exports and confirm completeness. Check custom fields, attachments and free-text notes, which are often missed.
Ticketing and helpdesk records
Support tickets, chat transcripts and telephone notes often contain personal data that no one planned to store long term. A helpdesk such as Zammad consolidates email, chat, telephone and social media into one ticket system, which simplifies searching but also means attachments and merged tickets must be checked. Confirm who in support can retrieve closed tickets and whether internal notes are included in the response.
Email archives and collaboration files
Mailboxes, shared drives and collaboration spaces hold correspondence that names the requester, often outside any formal record. Decide with legal which archives are in scope, how far back searches go, and how third-party personal data inside a message is redacted. Document the search terms and the custodians searched so the response can be reproduced if the authority asks.
Backups, logs and activity records
Activity logs and records of searches can themselves be personal data within scope, and pseudonymised data remain personal data. Logs from endpoints and monitoring tools, such as inventory data held by Wazuh or host records in Zabbix, can link a person to a device or session. Agree a retention position for logs and decide whether backups are searched or only covered by a stated restore process. Confirm the position with counsel before answering.
Paper filing systems
Article 15 covers non-IT filing systems where personal data are structured to allow retrieval of information about a person. Personnel folders, branch paperwork and archived contracts can fall within scope when they are organized by name or a similar identifier. Identify which paper sets are structured this way, store a register of them and name the site or department that holds each one.
Processors, sub-processors and recipients
Hosting providers, payroll bureaus, email services and support vendors may hold copies that must be searched. Recipients who received the data must be named in the response where the controller discloses them, so the contract register should show what each processor holds and where. Confirm with each processor how it will support searches and deadlines, and record the sub-processors that sit beneath it.
How an assessor tests the access response process
This table sets out how an assessor tests each part of the access response process, what evidence they ask for, and where organizations most often fall short. Read it as a checklist: each row maps a test to the proof you should have ready before a regulator or auditor asks. The main takeaway is that undocumented procedures and over-broad identity checks are the findings most often seen in practice.
| Test approach | Evidence requested | Common findings |
|---|---|---|
| Walk through a sample of requests from intake to response | Request log with receipt dates, identity check records, search records, response copies and dispatch dates for a sample of closed requests | Requests logged but not timed, so the one-month deadline cannot be shown as met; no record of who approved the response |
| Test the search across systems against the data map | Current data map or records of processing, the search criteria used per system, and search logs showing which IT and paper systems were queried | Searches limited to the main CRM or HR system; shared drives, email archives, backups in scope, paper files and vendor-hosted tools not searched |
| Check that identity requests were proportionate | Copy of the identity request template, the data points requested per case, and examples where extra checks were waived or escalated | Requests for copies of passports or national ID for low-risk data; the same check applied to every request regardless of sensitivity |
| Check the security of response delivery | Delivery method per request, encryption or access controls on the channel, and records of the recipient address or portal used | Unencrypted email attachments; responses sent to an address that differed from the verified contact on file; portal links that did not expire |
| Check that activity logs and search records were handled as personal data | Retention rules for access logs and search records, and a statement on whether they were included in responses | Logs used to answer requests but not retained, or logs kept indefinitely with no stated purpose |
| Check that the procedure is documented and followed | Written access procedure, assigned owners, staff training records and the version history showing when it was last reviewed | Procedure exists only in one person's knowledge; documented steps differ from what staff actually do; no review after system changes |
| Check the supporting information provided with the copy | Template response showing purposes, recipients including third-country recipients, retention periods, rights notice and source of data | Responses that give a copy of the data but omit recipients, retention or the source, or use generic wording that does not match the records |
| Check that refusals and fees were justified and recorded | Refusal letters, the reasoning recorded for each, and any fee calculation for further copies | Refusals without a documented basis; fees charged for first copies or without a stated reasonable cost basis |
How to build an access response process that finds all the data
This sequence turns an Article 15 request into a repeatable workflow: know where personal data sits, search it the way it is stored, verify identity proportionately, and produce a complete response that a regulator could follow from intake to delivery.
Map personal data sources and owners
Start with a register of every system and filing location that holds personal data about customers, employees and other individuals. Include production applications, databases, file shares, email, backups, logs, SaaS tools, paper archives and copies held by processors. Name a business owner for each source and record which identifiers it uses, such as name, email, customer number, employee number or national identifier. The step is done when each source has an owner, a documented search key and a note on whether it sits inside your infrastructure or with a processor. Keep this register aligned with your records of processing so the two do not drift apart.
Write the search procedure around data structure
For each source, write the exact search steps an analyst follows. The EDPB expects searches to use criteria that mirror how the data are structured, so a customer record keyed by customer number should be searched by that number, while a mailbox or file share may need name and address variants. Include non-IT filing systems such as paper HR files and archived forms. Define what to do with pseudonymised records, which remain personal data, and with activity logs and search histories that may themselves fall within scope. The step is done when a second analyst can run the procedure for a test identity and reach the same set of sources without asking the author.
Set proportionate identity verification rules
Define when you need to confirm who is asking and what proof is enough. The EDPB says requests for extra identity information must be proportionate, so a logged-in customer with an authenticated session may need no further check, while a request from an unauthenticated channel may need one or two data points already held on file. Document the methods you accept, the data you will never request, and how you handle a doubtful identity without over-collecting. Record the decision in the ticket. The step is done when frontline staff can apply the rules from a one-page standard and when no rule asks for more data than the request needs.
Define the copy and supporting information template
Build a response template that covers the confirmation of processing, a copy of the personal data, and the supporting information in Article 15(1): purposes, categories, recipients (particularly those in third countries), retention periods, rights available, the source of the data, and any automated decision-making. Pull retention and recipient details from your records and privacy notices so the answer matches what systems actually do. Decide the electronic format for the copy and state that the data subject may ask for another form. The step is done when a sample response for a test identity is complete, consistent with your records of processing, and reviewed by the DPO or privacy lead.
Assign roles, deadlines and escalation paths
Name who owns intake, who runs each system search, who reviews the bundle for third-party data and exemptions, who signs off the response and who is the escalation point when a source owner is unavailable. Write the internal deadlines against the one-month response period that Article 12 sets, and confirm the current extension and fee rules with counsel before you publish them. Separate the roles where practical so the person who collects data is not the only reviewer. The step is done when the RACI is approved, each role holder has accepted it in writing, and the escalation path has been checked against a holiday or absence scenario.
Configure intake channel and ticket workflow
Set up one intake route, such as a web form, a privacy mailbox or a portal, and make sure requests received by any other channel are forwarded into the same queue. Use a ticketing system that can track each request from receipt to closure, assign tasks to source owners, and keep the search log and the final response together. Open-source helpdesks such as Zammad bring email and other channels into one ticket system, while GLPI's Assistance module supports ITIL-style tickets, planning and statistics. Confirm each product's capabilities against the version you deploy. The step is done when a test request enters the queue, generates tasks for each source and produces a closed record with timestamps.
Run a tabletop test with a sample request
Simulate a complete access request for an invented identity held across several systems, a paper file and a processor. Ask the team to follow the written procedure step by step, including identity checks, searches, redaction of third-party data and drafting of the supporting information. Time each handoff and record every gap, such as a source with no owner, a search key that misses records, or a template field nobody can fill. Fix the procedure and re-run the parts that changed. The step is done when the exercise produces a list of findings, each with an owner and a closure date, and the test scenario is stored for future audits.
Review the process after the first live requests
After the first real requests close, review the ticket records against the procedure. Check whether searches found what they should, whether identity checks stayed proportionate, whether the response contained every element of Article 15(1), and whether any deadline was missed or came close. Update the source register, search steps and templates where the review finds drift, and record the changes with version and approval. Track the volume and types of requests to spot patterns that point to missing sources or unclear notices. The step is done when a dated review record exists, the procedure carries a new version number, and the open actions are assigned.
Evidence that shows the right of access works
An access response is only as defensible as the records behind it. The six artifacts below show that requests are found, verified, answered and delivered the same way each time, and that the procedure matches what the systems actually do. Keep each one current between reviews so it reflects the systems as they run today.
Written access procedure
A dated, approved procedure that sets out intake channels, the steps from receipt to response, who searches which systems, how the response is reviewed and who signs off. Regulators have cited undocumented procedures as a common gap in access compliance, so this is the first document an assessor will ask for. Check that it names real owners and matches how staff actually work. Review it whenever a system is added, retired or moved, and record each revision with its date and approver.
Data source inventory and search criteria
A register of every IT system and paper filing system that may hold personal data, with the search criteria each one supports, such as name, customer number or account identifier. The EDPB expects searches to mirror how data are structured, so an inventory that lists only the main database leaves gaps. Confirm that each source has an owner, that its criteria are tested, and that backups, logs and shared drives are either included or excluded with a documented reason.
Request register with timestamps
A log of every access request with its receipt date, verification date, deadline, extensions, systems searched, outcome and the person who closed it. This register lets you show that responses met the Article 12 timing and that refusals or fee decisions were recorded. Ticketing tools can hold this record if fields are fixed and cannot be edited after closure. Check that the register is complete by sampling against mailbox and ticket records.
Proportionate identity verification records
Records showing what identity information was requested, why it was needed for the data involved, and how it was checked and then discarded or retained. The EDPB says extra identity information must be proportionate, so a request for a copy of a passport to release a marketing preference is an over-collection risk. Keep the verification standard per data category in the procedure, and record each case against it. Confirm that verification documents are deleted on a set schedule.
Delivery records and secure transfer
Evidence of how each response left the organization: the channel used, the encryption applied, the recipient confirmed against the verified identity, and the date of dispatch. Article 15(3) allows electronic requests to be answered electronically in a commonly used form unless the person asks otherwise, so the transfer method must be both usable and secure. Check that secure portals or encrypted archives are configured, that passwords are sent separately, and that failed or returned deliveries are logged.
Reviewed search and access logs
Samples of the audit trails generated while staff and systems searched for a data subject's records, reviewed to confirm the search was complete and the logs themselves were handled correctly. The EDPB notes that activity logs and search records can be personal data in scope, so they must be included in the response where relevant and minimized otherwise. Wazuh inventory data or Zabbix host records can help show which systems held data at a given time. Confirm that periodic reviews are signed and that log retention is defined.
What meeting Article 15 costs in money and effort
This table lists each cost component of answering access requests, who is paid for it, whether it is one-time or recurring, and what changes it. The GDPR sets no price for compliance, and the Article 15(3) fee for further copies is something the controller may charge a requester, not a cost of compliance. Use the last column to build the questions you put to any quote.
| Cost component | One-time or recurring | What drives it up or down | What to ask for in a quote |
|---|---|---|---|
| Tooling and licenses | Recurring for commercial helpdesks, one-time setup otherwise | Self-hosted open-source tools such as GLPI or Zammad remove license fees, but configuration and support effort remain | Itemized license fees, hosting resources, and support hours for ticket workflow setup |
| Engineering time for connectors and search | One-time build, then recurring maintenance when systems change | Number of systems holding personal data, whether identifiers mirror how data are structured, and use of pseudonymised keys | Connector list by system, search criteria per system, and effort to rerun searches after upgrades |
| Legal and DPO review of responses | Recurring per request or per batch | Complexity of exemptions, third-country recipients, and disputed or large requests | Review steps, who signs off, and turnaround assumptions written into the scope |
| Staff time per request | Recurring | Volume of requests, number of manual paper or non-IT filing systems, and quality of intake forms | Estimated handling steps per request type and how the workflow records time spent |
| Identity verification | Recurring | Sensitivity of the data, need for proportionate checks, and whether secure channels already exist | Verification method by data category and confirmation that requests for extra identity data are limited to what is necessary |
| Secure delivery of copies | One-time setup, then recurring operation | Size of exports, choice of electronic form, and whether the requester uses a secure portal | Delivery channel, encryption method, and how the export is logged as processing |
| Evidence upkeep | Recurring | Frequency of inventory changes, log retention, and how often procedures are reviewed | Evidence list per request, retention period for request records, and review cycle |
| External review or testing | Periodic, scope-dependent | Whether a third party tests the workflow, search coverage, and response quality, and how often | Written scope, deliverables, and who issues any assessment report (only an independent auditor or certification body issues reports) |
Open-source tools that support intake, tracking and data location
Four self-hosted open-source platforms can supply parts of the evidence an Article 15 response depends on: a dated intake record, a tracked workflow, an inventory of where systems and their owners sit. None of them finds personal data inside records or searches paper files, so the controller still designs the search criteria and the manual steps. Confirm each capability in the version you deploy before you rely on it.
GLPI for request tickets
GLPI's Assistance module lets staff create, follow and process tickets using ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. Used as the access request register, it can hold the receipt date, due date, assigned owner and closure record for each request. It does not search application databases, mailboxes or paper files for a data subject's records. Its GPL-3.0-or-later license permits modification and redistribution under its terms, so have counsel confirm the obligations that apply to your deployment.
Zammad for multichannel intake
Zammad is a web-based helpdesk that brings email, chat, telephone and social media messages into one ticket system. Its value for Article 15 is consistency: requests that arrive through several channels land in one queue, which reduces the chance that a request sent to a support mailbox is lost. It does not decide whether a message is a valid access request, and it does not search other systems. Its AGPL-3.0-only license carries network-use source obligations for modified versions, so confirm them before you change the code.
Wazuh for endpoint inventory
The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint. Those inventories help the controller show which hosts and user accounts exist, which is a starting point for mapping where personal data may sit. Inventory does not reveal what personal data a file contains, and it does not cover paper records or SaaS data stores that have no agent. Its GPL-2.0-only license should be checked against how you bundle it with other components.
Zabbix for host ownership
Zabbix host inventory records details such as device type, serial number, location and responsible person, either entered manually or populated from agent items for hardware, OS and installed packages. Named owners and locations let the team reach the right person quickly when a search has to cover a host. It does not know which hosts hold personal data unless someone records that, so keep a data-category field or link to your records of processing. Its AGPL-3.0-only license applies to modified versions, so confirm the obligations with counsel.
Who owns the access response and who prepares the evidence
As controller, your organization owns the access procedure from intake to response. Regulators hold you accountable for every decision, including whether a request is valid, how far the search goes, whether any exemption applies and what is finally disclosed. No vendor or consultant can take those decisions over.
- Procedure ownership: Approve the written access procedure, name the owner for each step and keep it current when systems change.
- Exemption and redaction decisions: Decide when third-party data or other protected information must be withheld or redacted, and record the reasoning.
- Response sign-off: Review each response before release, confirm it covers the required information under Article 15, and confirm the deadline status.
- Accountability records: Keep the request log, identity verification notes, search records and copies of what was sent so you can show what happened.
- Staff training: Make sure frontline staff recognize access requests in any channel, including email, post and social media.
Check that a named person inside your organization can explain and defend every response in front of a supervisory authority.
An implementation partner such as DeployOpen prepares the systems, workflows and evidence your team uses. It configures request intake and ticketing in the client's own infrastructure, builds search connectors to the systems that hold personal data and prepares templates and records. It does not decide what is disclosed and does not issue reports, attestations or certificates.
- Intake and ticketing: Configure request channels and ticket workflows so each request gets an identifier, a due date and an owner. Ticketing tools such as GLPI or Zammad can hold this workflow.
- Search connectors and inventories: Build or document searches across IT systems, using inventories from tools such as Wazuh or Zabbix to locate hosts and applications that may hold personal data.
- Evidence templates: Prepare response templates, search logs and records of processing activity so each step leaves a trace.
- Documentation: Write runbooks that explain how each system is searched and where its data is exported.
- Limits of the role: Work stays within the written scope. Your team remains the decision maker for every response.
Confirm in the written scope which systems are covered and who signs off each deliverable.
No certificate exists for Article 15. Supervisory authorities enforce the right of access, and independent assessors who test your process do so as a matter of review, not certification. Their work tests whether the process works in practice, usually through sampling of past requests and interviews with staff. Independence means an assessor cannot be prepared or advised by the party whose work is under review in ways that compromise its judgment.
- Process testing: Expect the reviewer to walk a sample of requests from intake to response and compare the outcome with the procedure.
- Search evidence: Expect questions about which systems were searched, with what criteria and how paper and log data were handled.
- Timing and identity checks: Expect checks on deadlines, extensions and whether identity verification was proportionate.
- Independence limits: An implementation partner may explain the evidence it prepared, but it should not perform the assessment or shape conclusions.
- Regulator contact: Keep records ready in case a supervisory authority asks for them directly.
Confirm with your legal team whether any independent review is expected in your sector and who engages the reviewer.
Where access response processes usually fall short
The EDPB's guidance and its 2024 coordinated action point to a small set of recurring weaknesses in access responses. Most come down to undocumented procedures, incomplete searches, identity checks that outrun the request, and thin records of what was sent and when.
Undocumented, person-dependent procedures
When one staff member knows how requests are logged, searched and answered, the process fails as soon as that person is absent. The 2024 coordinated action flagged undocumented procedures as a common challenge. Check that a written procedure names the intake channel, the owner of each step, the search criteria, the review by the data protection function, and the approved template for the response. Test it by having someone who did not write it run a sample request from start to finish.
Searches limited to the main CRM
Access searches often stop at the customer database, while the same person's data sit in email, shared drives, support tickets, HR tools and marketing lists. The EDPB guidance requires the controller to search all IT systems and non-IT filing systems, using criteria that mirror how the data are structured, such as name and customer number. Build a system inventory and map each search source to a named owner before the first request arrives.
Backups, logs and paper files left out
Activity logs and records of search activity can themselves be personal data within scope of an access request. Paper files, archived mailboxes and exported spreadsheets are also frequently skipped. Confirm which logs hold identifiers for the requester, how long they are kept, and whether restoring a backup is needed to answer a request. Document the decision for each source, including where the data were searched and found to be absent.
Identity checks beyond what the request needs
Requests for extra identity documents can become excessive data collection. The EDPB guidance says identity information requested must be proportionate to the request and the data involved. Define a tiered check: confirm identity from data already held where possible, ask for limited extra details only when there is real doubt, and avoid collecting copies of identity documents by default. Record the reason for every additional check.
Responses that omit recipients and retention
Article 15 also requires information on recipients, particularly those in third countries, the retention periods, the source of the data and the purposes. Responses often send the data file alone. Keep the record of processing current and link it to the response template, so each access response is built from the same record of recipients, transfers and retention periods that the organization maintains.
No record of receipt and response
Without a dated record of when a request arrived, what was searched, what was sent and how it was delivered, the organization cannot show it met the deadline or explain its handling to a supervisory authority. Use a ticketing system to log each request with timestamps, assigned owners, search results and the final response. Set alerts on the response deadline and keep the closed record with the evidence of secure delivery.
Questions buyers ask about Article 15 implementation
How much effort does an Article 15 access process take to run?
The effort depends on how many systems hold personal data, how well those systems are indexed by name, customer number or other identifiers, and how many requests arrive in a year. Most of the work is not the export itself. It is finding every place a person's data sits, including IT systems, email, shared drives, backups where relevant, logs that contain personal data and paper filing systems. A one-time build covers the data map, search procedures, templates and delivery channel. Recurring effort covers intake, identity checks, search, review, redaction of third-party data and the response itself. Ask any provider to split its quote into the one-time build and the per-request work, and to state which systems it assumes are in scope.
Can we run access requests in-house without outside help?
Yes, a controller can run this process in-house. The GDPR does not require an outside party, and no certification is needed to respond to a request. Teams with a current record of processing, a clear list of systems and a helpdesk that already tracks tickets are usually closest to ready. Teams without those usually need to build the inventory first. Outside help is most useful for mapping systems that no one fully owns, configuring a ticketing workflow, writing search procedures and testing that the response pack is complete. Whatever the split, the controller keeps responsibility for the response.
How long does implementing an access process take?
The timeline depends on scope, and no duration is fixed by the regulation for the implementation work itself. The main variables are the number of systems to map, whether a ticketing platform already exists, how many business units hold personal data, and whether paper records are involved. Ask the provider to state in writing which systems, data sources and request channels are included, what the client must supply, and which deliverables close the engagement. Vague scope is the most common reason timelines slip. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the quote should follow directly from that written scope.
What does the business and IT team need to provide?
The work needs input from both sides. The business owns the purposes, recipients and retention rules that a response must describe under Article 15(1). IT owns the systems, identifiers, logs and export methods that produce the data copy. Typically the business must confirm which processing activities exist and who approves responses, while IT must confirm where data sits, how it can be searched and who holds administrative access. Legal or the data protection function usually reviews redaction of other people's data. Agree these responsibilities in writing at the start, because unclear ownership is one of the challenges that regulators reported in the 2024 coordinated action on this right.
Can an outside party answer access requests for us?
A processor or service provider can handle parts of the workflow under a written processing agreement, such as intake, logging or hosting a request portal. The controller remains responsible for the response, for the identity check and for the decision on what to disclose. Any outside party that sees the personal data must be bound by contract and by the security measures the controller relies on. Ask whether the provider will act on your instructions only, where the data will be held, which sub-processors are involved and how the exchange with the data subject is secured. An outsourced DPO or EU representative is a separate service and does not replace the controller's duty.
What will an auditor or regulator ask to see for access requests?
Auditors and regulators usually ask for evidence that the process works as written, not only that a policy exists. Expect requests for the written procedure, the list of systems searched and the search criteria used, a sample of past requests with timestamps, identity checks applied, secure delivery records and any refusals with reasons. Under the EDPB guidelines on the right of access, controllers must search IT and non-IT filing systems using criteria that mirror how the data are structured. Regulators also check that identity requests are proportionate. Note that the GDPR requires no audit or certificate, so any external assessment is voluntary and does not replace the controller's own responsibility.
How DeployOpen scopes and prepares access request evidence
DeployOpen works on Article 15 as a fixed-scope implementation: we map where personal data sits across your self-hosted platforms, build the search and export workflows, and document them so your team can answer access requests. The controller stays responsible for every response, and independent assessors or auditors verify the result.
How we scope
- The written scope lists which systems, ticketing tools, file shares and paper filing locations are in the access request search.
- Scope names the data subject identifiers used for searching, such as name, customer number and email address.
- Scope states who owns each step: your privacy team decides what is disclosed, and DeployOpen prepares the technical workflow.
How we build
- We configure self-hosted platforms so tickets, customer records and inventory data can be searched by the same identifiers.
- We test search coverage against a sample set of records to confirm that no system holding personal data is missed.
- We set up logging for search and export activity, since the EDPB treats those logs as potentially in scope for access requests.
How we hand over
- You receive runbooks describing intake, identity checks, search steps, export formats and secure delivery of the response.
- Documentation records the systems in scope, their owners and the search criteria, so the procedure can be repeated and reviewed.
- Handover includes a walkthrough with your team, and our work is limited to preparing evidence rather than issuing any attestation.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover updates to the search workflow when new systems or data stores are added to your environment.
- Confirm with us in the written scope which support levels, response expectations and review cycles apply to your environment.
