How to meet Article 32(1)(d) regular testing without guessing what regulators expect
Article 32(1)(d) asks the controller or processor to run a process that regularly tests, assesses and evaluates whether the security measures protecting personal data actually work. In plain terms, having firewalls, encryption and access controls is not enough on its own. You need a repeatable routine that checks those measures on a schedule, records what the checks found, and shows that problems were fixed. A single penetration test before go-live, or a security policy that says testing happens, does not meet this. The risk the provision addresses is simple: controls degrade through misconfiguration, unpatched software, drift after changes and staff turnover, and an organization that never checks will not know until a breach shows it. The GDPR requires no audit, attestation or certificate for this. The obligation sits with you, and the process is yours to design and run, even when an outside firm performs some of the tests.
The provision is hard to meet for three recurring reasons. First, nobody owns the process, so tests get commissioned ad hoc and no one notices when a quarter passes with nothing run. Second, there is no written schedule that ties each test to a system, a data set and a risk level. Third, findings are logged but never tracked to closure, so the same weaknesses reappear in the next scan. Article 24(1) reinforces the point by requiring controllers to review and update their measures where necessary, and EDPB Guidelines 4/2019 on data protection by design call for regular review of how well those measures perform during processing. Start by naming one accountable owner, a schedule per processing system, and a rule for how long a finding may stay open before escalation. Confirm these choices with your own supervisory authority's guidance and with your legal team, since the GDPR does not set frequencies.
Evidence is what an assessor or regulator will ask for first. Keep scan and test reports with dates and scope, a register of findings with owner, severity, decision and closure date, retest results, and records showing that restore tests and configuration checks ran. Where you use a platform such as Greenbone Community Edition (OpenVAS) for scanning or DefectDojo to consolidate findings, confirm that the exported records carry the dates, scope and status a reviewer needs before you rely on them. Processors face the same test in another form: Article 28(3)(h) requires them to make information available and allow audits, so a documented testing cycle is also what your customers will request from you. A readiness review of this process, performed by an independent party, can show gaps before a regulator does.
Which systems, data and third parties fall under regular testing
Article 32(1)(d) only asks for testing of the measures that protect personal data, so the first decision is which systems, accounts and parties sit inside that boundary. Each card below names a scope choice and shows how it changes the testing workload, the evidence an assessor will ask for, and who can be asked to contribute.
Production systems holding personal data
Start with a data inventory that maps each production system to the personal data it stores or processes. Systems that hold personal data are in scope even when they look like infrastructure, such as directories, log stores and message queues. Test them on the same cycle as the applications that write to them, and record which findings affect personal data so the output can be traced back to the processing records. Ask the team to confirm that the inventory is current, because an out-of-date map is the most common reason a test misses a system.
The processing chain and sub-processors
Every service that receives personal data from your environment belongs in the testing picture, even when another company operates it. Decide which sub-processors you test directly, which you review through their own audit reports, and which you cover through contractual rights to inspect. Processors must make available the information needed to demonstrate compliance and must allow audits by the controller or an auditor it mandates under Article 28(3)(h), so contracts should state how that testing is shared and how often it runs.
Endpoints and cloud accounts
Laptops, servers, containers and cloud accounts that can reach personal data form a separate testing surface with its own cadence. Vulnerability detection on endpoints checks installed software against vulnerability sources, while configuration checks look at storage permissions, logging settings and network exposure in cloud accounts. Each new account, subscription or region that joins the environment should trigger a scope update, because a test that covers the main account but not a forgotten staging account leaves personal data unexamined.
Applications and APIs
Web applications and APIs are where personal data is most often exposed to users who should not see it, so they need penetration testing that covers authorization between accounts, not only injection flaws. Scope each application by the data classes it handles and the number of endpoints that return personal data. Retest after material changes, and keep the test report linked to the release that was tested so an assessor can see that the testing followed the software that is actually in production.
Backup and restore paths
Backups hold copies of personal data that often sit outside the normal monitoring scope. Include backup storage, replication targets, backup administrator accounts and restore procedures in the test plan. Restore tests should confirm that data comes back intact, that access controls survive the restore, and that deleted records do not reappear unless the restore is intentional. Ask for evidence of the last restore test and its result, not only the backup job logs.
How an assessor tests Article 32(1)(d) regular testing
This table compares what an assessor checks for each part of a regular testing process, the evidence they ask to see, and the findings that usually show a gap. Read each row as a question the assessor will put to the controller or processor, then check your own records against the evidence column before the review starts.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Documented testing programme with scope and frequency | Written testing policy or procedure, defined asset scope, stated test frequency per system, and the approval record for that plan | No written programme, scope that omits personal data systems, or frequencies set informally and not followed |
| Scans and penetration tests run on schedule against defined scope | Scan schedules, dated scan and penetration test reports, the target lists used, and records showing which systems were covered | Scheduled scans that silently failed, new systems missing from target lists, or tests that stopped before the agreed scope was complete |
| Configuration and change checks when new software is installed | Pre-installation checks, hardening baselines applied at deployment, change tickets showing a security check before go-live, and post-change scan results | No check before new software reaches production, as cited in the Swedish IMY fine against Miljödata of 22 September 2026, or checks that were not repeated after updates |
| Restore tests included in the testing process | Dated restore test records for personal data, the systems and data sets restored, and the time and outcome recorded for each test | Backups never restored in testing, restore tests that covered only system files and not personal data, or failed restores with no follow-up |
| Findings tracked to closure | Issue register with severity, owner, due date, remediation evidence and retest result, plus records of accepted risks with sign-off | Open findings older than the team's own deadlines, findings closed without retest, or duplicate entries that hide the real backlog |
| Review feeds back into measures | Management review minutes, updated risk assessment or control records, and documented changes to measures triggered by test results | Test results that never change a control, risk registers not updated after a finding, or no link between incidents and the testing plan |
Implementing a testing process that runs between audits
This sequence turns Article 32(1)(d) into a repeatable cycle: scope and frequency are set from risk, tests are run and recorded by named owners, findings are fixed and retested, and the measures are reviewed on a schedule the organization can show. Each step ends with a record an assessor or supervisory authority can inspect.
Set testing scope and frequency from risk
Start from the risk assessment that underpins your Article 32 measures. List every system that processes personal data, including production, staging, backups, logging pipelines and sub-processor-hosted components, and rank them by the risk to individuals if they fail. Set a testing frequency for each tier and record who approved it. The output is a scoped asset register with a testing calendar and the risk rationale behind each frequency, which you can show an assessor as the basis for every later test.
Select test types for each asset class
Match test types to asset classes. Vulnerability scanning and configuration checks suit servers, containers and endpoints; penetration tests suit internet-facing applications, APIs and high-risk internal paths; restore tests suit backup and recovery of personal data; access reviews and log checks suit identity and monitoring controls. Document why each test type fits each class and what it does not cover. The output is a test matrix that links each measure to the test that evaluates its effectiveness, so no control relies on a test that cannot detect its failure.
Schedule and run tests with named owners
Assign a named owner to every test and a named reviewer to every result. Schedule tests in the calendar from step one, run them with approved tooling or an independent tester, and keep scan credentials, scope limits and change windows in the test record. When a change is made to a system, such as a new software install, check that its configuration and vulnerability status were tested before it went live. The output is a dated test log with owners, tools, scope and completion status for each run.
Record and deduplicate findings
Load results from every scanner and tester into one findings register rather than leaving them in separate tool consoles. Deduplicate repeated findings across scans and tools so the same flaw is tracked once, and tag each finding with the asset, the measure it affects and its severity. Record any test that found nothing as well, with its scope. The output is a single register in which each finding has an identifier, an owner, a status and a link to the test that produced it.
Track remediation and retesting
Assign each finding a remediation target agreed with the risk owner, and record the fix, the change ticket and the date it was applied. Retest the affected asset after each fix and close the finding only when the retest confirms the issue is gone. Where a risk is accepted instead of fixed, record who accepted it, why and when it will be reviewed. The output is a closed-loop record for each finding showing the original test, the fix, the retest result and any accepted risk.
Review measures periodically and document decisions
At a fixed interval, review whether the measures still work against current threats and whether the testing scope still matches the systems in use. Compare trends in findings, missed tests and accepted risks, and update the risk assessment and test matrix where needed, as Article 24(1) expects for measures that must be reviewed and updated. Record each decision, its rationale and the approver. The output is a dated review pack that shows the process runs between audits, not only before them.
Evidence that shows Article 32(1)(d) regular testing actually runs
Article 32(1)(d) is satisfied by a process you can demonstrate, not by a single test. The cards below cover the records that show testing is planned, executed, acted on and reviewed, and the habit of keeping those records current between assessments.
Testing policy with scope and frequency
The written standard that defines which systems, personal data flows and processors fall within testing scope, which test types apply to each, and how often each one runs. An assessor will compare what the policy promises with what the dated records show. Check that the policy names an owner, covers cloud and self-hosted components alike, and is approved at a level that can fund the work. Illustrative: a policy that requires quarterly scans but has no restore tests listed leaves a gap an assessor will notice.
Scan and test schedules
Calendars or scheduled tasks that show when vulnerability scans, penetration tests, configuration checks and restore tests were planned to run. Schedules prove the process was designed to repeat rather than triggered by an incident or an audit notice. Confirm that the schedule covers each in-scope environment and that changes to the schedule are themselves recorded. In Greenbone Community Edition, scan tasks are scheduled through gvmd, so the schedule export can serve as evidence.
Dated scan and test reports
The output of each run, with the date, target, tool version, credentialed or uncredentialed mode, and the person who reviewed it. An undated or unattributed report carries little weight because it cannot show the testing happened in the period under review. Wazuh vulnerability detection and Greenbone reports can be exported with timestamps, so retain the exports themselves rather than summaries written later. Ask whether each report shows the scope it actually covered.
Configuration check results
Results from baseline checks that compare installed systems against a hardening standard, such as operating system settings, database permissions and container configuration. They show whether security measures still work after deployment and after software installs, changes or upgrades. Regulators have cited inadequate checks when new software is installed, so record the check that ran before and after each change. Confirm that failed checks link to a remediation ticket.
Findings register with closure dates
A single register that lists each finding from every test, with severity, owner, status, planned fix date and the date it was verified closed. The register shows that testing leads to action, which is the part assessors test most closely. DefectDojo can deduplicate findings across tools using per-tool hashcode fields, which keeps one finding from being counted several times. Check that accepted risks carry a named approver and a review date.
Restore test records
Logs of periodic restores of personal data from backup into a test environment, showing the date, the dataset, the time taken, whether the restored data was complete and usable, and who signed off. Restore tests check the availability and resilience measures that Article 32(1)(c) requires, so they belong inside the testing evidence. Record failed restores as findings with their own closure dates. Confirm the test covers the systems that hold the most sensitive personal data.
Review minutes showing updated measures
Minutes from security or data protection reviews that show the results of testing were discussed and led to changes in measures. Article 24(1) expects controller measures to be reviewed and updated where necessary, and EDPB Guidelines 4/2019 expect regular review of effectiveness during processing. Minutes should name the decision taken, the measure changed and the evidence it was changed. Attendance lists and agenda items give an assessor a trail to follow.
Keeping evidence current between audits
A retention routine that exports and timestamps each record as it is created, then stores it in a location the audit team can read later. Screenshots taken on the day of an assessment show the state of a system on that day only, and they invite questions about whether earlier periods were tested. Set a retention period that covers the review window your auditor or supervisory authority will examine, and confirm it with your legal team. Test the routine itself by pulling a record from several months earlier.
Self-hosted open-source tools that produce testing evidence
Endpoint tools answer a basic question: which operating systems and installed applications on the systems that process personal data have known vulnerabilities right now. Wazuh (GPL-2.0-only) collects a software inventory from each monitored endpoint through its agent, then correlates that inventory with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy where endpoints cannot reach the internet. Fleet (MIT) takes a similar approach for enrolled hosts, matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV.
- Inventory-based findings: Each agent or enrolled host produces a dated list of installed software and the vulnerabilities matched to it, which can be exported as a record of what was checked and when.
- Offline operation: Wazuh supports a locally hosted copy of its vulnerability content, which matters for air-gapped or restricted networks. Confirm how often the offline copy is refreshed in your environment.
- Source coverage differs: Fleet's matching depends on the advisory sources it reads for each operating system. Confirm which sources cover the platforms you run.
- Change detection: Rerunning matching after patches or new installs shows whether a finding was closed or introduced, which supports the review step that Article 32(1)(d) describes.
- Scope limits: Endpoint inventory does not test configurations or application logic, so it needs to be paired with the scanning and testing evidence described in the other tabs.
Before relying on these outputs, confirm with your own asset register that every server, workstation and container image holding personal data is enrolled, and that agent coverage is reviewed on a schedule.
Network and host scanning checks what an attacker could reach from the network side: open services, missing patches and known weaknesses on hosts and devices. Greenbone Community Edition, built on OpenVAS and licensed under AGPL-3.0-or-later, is organized around the gvmd service. gvmd stores scan results in PostgreSQL, manages users and permissions, and schedules scan tasks, while users run scans and review results in the Greenbone Security Assistant web interface. The scheduled task history and stored results are the core of the evidence trail.
- Stored results: Scan reports and their timestamps are kept in the database, so you can show a dated record of each scan across the period an assessor asks about.
- Scheduled tasks: Recurring scan tasks create evidence that testing happens on a set cycle rather than only when someone remembers to run it.
- Access control for scan data: gvmd manages users and permissions, which lets you show who can configure scans and view results.
- Ownership of the result review: The web interface is where a named person reviews and triages results, so record that review step in your process documentation.
- Authenticated scanning: Confirm in the Greenbone documentation how credentialed scans are configured, because unauthenticated scans see much less of a host's software state.
Confirm the scan target list against your asset inventory, the scan schedule against your documented testing cycle, and the AGPL-3.0-or-later obligations with your legal team before you modify or distribute the software.
Scanners produce findings in different formats and repeat the same issue across runs. DefectDojo (BSD-3-Clause) is an open-source findings manager that imports and reimports results from more than 500 security tool report formats through its UI or API, including in the open source edition, and includes a generic findings import for formats it does not parse natively. It deduplicates findings using per-tool hashcode fields, so a recurring issue is tracked as one item rather than many.
- One record across tools: Findings from endpoint, network and application tests can sit in one place, which makes it easier to show the full testing picture to an assessor.
- Reimport history: Reimporting a newer report updates existing findings and shows which were resolved, which gives a traceable record of remediation.
- Deduplication logic: Hashcode-based matching depends on each tool's fields. Test the deduplication with a sample report from each tool you use before trusting the counts.
- Generic import for custom output: Scripts and in-house tests can feed the generic import, so bespoke testing can be recorded alongside commercial and open-source tool output.
- Ownership and sign-off: DefectDojo records status changes, but a named owner must still accept risk, assign remediation and close findings.
Before you rely on DefectDojo as your evidence store, confirm which report formats your tools produce, verify the deduplication behavior on your own data, and confirm that your retention rules cover the findings history.
What regular security testing costs under Article 32(1)(d)
This table breaks the cost of a regular testing program into its components, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to keep it down. Use it to request quotes broken down the same way, because a written scope is what turns these components into figures. The main takeaway is that open-source scanners remove license fees but not the recurring work of hosting, tuning, reviewing findings and keeping evidence current.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Tooling or licenses | Recurring for hosting, one-time for initial setup | The named open-source tools (Wazuh, Fleet, DefectDojo, Greenbone Community Edition) carry no license fee, but they need servers, storage, updates and administration | Reuse existing hosting and monitoring, and confirm the license terms of any commercial add-on before adopting it |
| Engineering time to configure scans and integrate findings | One-time, with periodic rework | Number of asset types, authenticated versus unauthenticated scanning, and how many findings feeds need mapping into one tracker | Start with the systems that hold the most personal data, and standardize scan profiles and asset tags |
| Evidence upkeep | Recurring | How many test cycles must be documented, how findings are triaged and closed, and how long records are retained | Automate report export and keep one register of tests, owners and remediation dates |
| External penetration testing or review | Recurring, usually per test cycle | Scope size, number of applications and APIs, cloud and network complexity, and whether retesting is included | Define scope in writing, test on a stated cadence, and ask for retest terms up front |
| Auditor or assessor sampling effort | Recurring, per assessment | How many test records and remediation cases the assessor samples, and how easily evidence can be traced to a specific system and date | Keep a consistent evidence trail so sampling does not require manual reconstruction |
Who owns testing, who prepares the evidence and where the auditor stops
The controller or processor owns Article 32 compliance. That includes deciding which systems are in scope for testing, how often tests run, which findings must be fixed and which risks are accepted, and who signs off on that acceptance. Article 32(1)(d) asks for a process for regularly testing, assessing and evaluating the effectiveness of security measures, and the organization is accountable for that process existing and being followed, whoever carries out the individual tests.
- Scope decisions: Naming the systems that hold personal data, the internet-facing services and the processors whose platforms must be tested.
- Test cadence and triggers: Setting regular intervals and extra tests after major changes, such as new software installed in production.
- Risk acceptance: Recording who accepts each unresolved finding, with a reason and a review date.
- Remediation ownership: Assigning fixes to named teams and tracking them to closure.
- Management review: Ensuring leadership sees trends and decides on resources.
Check that your testing policy names an accountable owner, that scope and cadence are written down and that risk acceptances are signed by someone with authority to take the risk.
An implementation partner such as DeployOpen can plan, deploy and configure the scanning and reporting systems inside your environment, integrate their findings into your ticketing and reporting workflows, and assemble the evidence that the process runs. This work happens under a written scope that defines systems, deliverables and timelines. Many organizations also outsource penetration testing and security testing to specialist firms, which may be the same partner or a separate provider.
- Tool deployment: Installing and hardening tools such as Wazuh, Fleet, DefectDojo and Greenbone Community Edition on infrastructure you own.
- Configuration and integration: Setting scan schedules, credentials, asset lists and report pipelines.
- Evidence assembly: Collecting scan records, test reports, remediation tickets and change logs into an evidence pack.
- Testing services: Running penetration tests or configuration checks within an agreed statement of work.
- Limits: The partner prepares systems and evidence. It does not decide risk acceptance and does not issue audit reports or attestations.
Check that the scope document separates partner deliverables from your own decisions and that the partner will not approve its own findings.
An independent auditor, assessor or certification body tests whether the testing process is designed and operating as described. It samples evidence, interviews staff, reviews records of decisions and checks that findings were handled. Only an independent party can issue a report, attestation or certificate. The GDPR itself requires no audit or certificate, but where certification under Article 42 is pursued, it is issued by an accredited certification body or supervisory authority.
- Process testing: Checking that scans and tests occur on the stated cadence and cover the stated scope.
- Evidence sampling: Selecting findings and tracing them to tickets, fixes and retests.
- Independence: A firm that ran the tests or assembled the evidence cannot also sign off the assessment of that same work.
- Reporting: The auditor alone issues the report or certificate, and it does not reduce the controller's or processor's responsibility.
- Boundary: The auditor tests your controls. It does not design them for you.
Check whether your auditor has a stated independence position on any consultant you engaged and ask how the evidence pack will be sampled.
Where organizations fall short on regular testing and how to close each gap
Article 32(1)(d) asks for a process that tests whether security measures work, not a one-off scan. The gaps below are the ones that most often separate a documented process from one that actually runs. Each card names one gap and one closure step that the organization owns, with an implementation partner able to help build it.
Findings with no owner
Scans run and reports are generated, but no named person owns the findings register, sets remediation deadlines or records accepted risks. Findings then age without decisions, and an assessor sees testing that never led to action. Close the gap by assigning an owner for each finding source and tracking every item to a closed, accepted or risk-accepted status. A tool such as DefectDojo can hold the register, but the ownership and decisions must be written down by the organization.
Scope limited to servers
Vulnerability scanning covers on-premises servers but skips cloud accounts, container images, web applications and APIs that hold personal data. The processing environment is then only partly tested, and the gap is usually found after an incident. Close it by writing the test scope from the data flow map, listing every system that stores or processes personal data, and assigning each one a test type, owner and frequency.
No check when software is installed
New software, libraries and agents are deployed without a configuration or vulnerability check against the security baseline. The Swedish IMY's Article 32(1) fine against Miljödata cited inadequate checks when installing new software among its failings. Close the gap by making a scan or configuration check a required step in the change process, with deployment blocked or flagged when the check fails.
Restore tests never run
Backups are taken and reported as successful, but no one has restored personal data from them to confirm the restore works within the required time. Testing the backup process is part of testing the effectiveness of the measure. Close the gap by scheduling restore tests against a sample dataset, recording the time taken and the data verified, and logging any failures as findings with owners.
Evidence assembled at audit time
Screenshots and reports are gathered only when an auditor or regulator asks, so the record does not show that testing happened on schedule. Regular testing is only demonstrable through dated, retained outputs. Close the gap by exporting scan results, configuration check reports and restore test logs automatically into a retained evidence store, with dates and the person who reviewed each one.
Sub-processor testing not requested
The controller relies on a processor or sub-processor hosting or operating part of the service, but never asks for that party's penetration test summaries, scan results or audit outputs. Article 28(3)(h) requires processors to make information available and allow audits, so the controller needs a routine way to obtain that evidence. Close the gap by adding a clause to processor contracts that sets the reports to be provided, their frequency and the remediation timeline for material findings.
Questions buyers ask about meeting Article 32(1)(d) testing
Does the GDPR require a specific type of security test or testing frequency?
No. Article 32(1)(d) requires a process for regularly testing, assessing and evaluating the effectiveness of security measures, but it does not name a test type, tool or interval. The controller or processor sets both from its own risk assessment, the sensitivity of the personal data, the systems involved and how quickly those systems change. A system that is updated weekly and exposed to the internet will usually need more frequent checks than a stable internal tool. Document the reasoning for the chosen frequency, because a supervisory authority will ask why the interval fits the risk. Your own risk assessment and any sector rules you also face are the sources to confirm before you set the schedule.
Does a penetration test alone satisfy the GDPR testing requirement?
No. A single penetration test is one input to the process, not the process itself. Article 32(1)(d) expects a repeatable cycle in which measures are tested, results are reviewed, weaknesses are fixed and the measures are reassessed. Vulnerability scanning, configuration checks, restore tests and internal audits fill the gaps between penetration tests. The evidence should show that the cycle runs on schedule, that findings have owners and deadlines, and that retests confirm fixes. A penetration test report with no follow-up record is weak evidence, because it shows one point in time rather than ongoing effectiveness.
How much effort does the testing process need from internal staff?
The effort is mainly ongoing and sits with the people who own the systems. Internal staff must decide scope, approve scan schedules, triage findings, assign remediation and sign off closure. Automated scanning reduces manual work but produces results that someone must review, and each finding that reaches a fix needs tracking. Effort rises with the number of systems, the rate of change and the number of tools feeding into one place. Ask any partner to split its estimate into one-time setup work and recurring work such as triage, retesting and evidence collection, and to name the internal roles each part assumes.
How long does it take to set up a testing process?
The duration depends on the scope you agree, and no fixed timeline applies to every organization. Setup usually covers inventory of in-scope systems, choosing tools, configuring scans and integrations, defining severity and remediation rules, and producing the first evidence records. Systems that already have asset inventories and ticketing workflows move faster. Confirm the duration in the written scope before work starts, including which systems are included, what the first full cycle will produce and which decisions remain with your team.
Can our team run this process in-house with open-source tools?
Often yes, provided the team has the skills and time to operate the tools and the evidence trail. Wazuh offers vulnerability detection that correlates each agent's software inventory with a vulnerability repository, or a locally hosted offline copy. Fleet detects vulnerable software on enrolled hosts by matching installed packages against sources such as the NVD and OSV. DefectDojo imports findings from more than 500 report formats and deduplicates them, which helps when several scanners run. Greenbone Community Edition schedules scans and stores results in PostgreSQL. Each tool needs configuration, updates and access control, and none of them replaces the decisions about scope, risk and remediation. Confirm each tool's current capabilities against its documentation before you commit to a design.
Can an outside partner prepare testing evidence without issuing an assurance report?
Yes. An implementation partner such as DeployOpen can plan the testing process, deploy and configure the tools inside your infrastructure, run agreed security tests, and organize the records an assessor or supervisory authority would ask for. The organization still owns its controls and decides what the evidence means. Only an independent auditor, assessor or certification body issues reports or certificates. The GDPR itself requires no audit or certificate, and Article 42 certification is voluntary and does not reduce your responsibility. Ask the partner to name the deliverables in writing, including which records you will own after the engagement ends.
How DeployOpen scopes, implements and prepares testing evidence
DeployOpen plans, implements and documents the testing program that supports Article 32(1)(d), running in your own cloud accounts, data centers or air-gapped networks. We prepare the systems, test records and evidence; your organization owns the controls and decides what testing is required, and an independent party is needed for any formal assessment.
How we scope
- Agreed in writing before work starts, with the systems, processing activities and testing types in scope listed explicitly.
- Scope sets which test types apply, such as vulnerability scans, penetration tests, configuration checks and restore tests, and how often each runs.
- Ask for the scope to name the owner of each control, the frequency of each test, and who receives and acts on the findings.
How we build
- We deploy self-hosted open-source scanners such as Greenbone Community Edition and Wazuh inside your environment, with access limited to in-scope systems.
- We configure scheduled scan tasks, endpoint inventory collection and findings storage so results are kept in a consistent, retrievable form.
- Where a central findings record is needed, we set up DefectDojo to import reports from multiple tools and deduplicate repeated findings.
How we hand over
- Deliverables include the test schedule, configuration records, scan and test reports, and a log showing when each test ran and who reviewed the results.
- Documentation covers how to rerun tests, how findings are triaged and how remediation is tracked to closure for later review.
- Handover includes a walkthrough so your security or compliance team can operate the process without DeployOpen involved day to day.
How we support
- Fixed-scope engagements end at the agreed handover, with any further work defined in a new written scope.
- Ongoing support, upgrades and continuous testing are available as a retainer, which keeps the testing cycle running after handover.
- Confirm with us which evidence an independent auditor or assessor will need, since DeployOpen prepares evidence but does not issue reports or certificates.
