Open source vulnerability scanning for PCI DSS 11.3: what the requirement asks and what Greenbone covers
A payments team facing a quarterly scanning obligation under PCI DSS v4.0.1 needs to know one thing first: Greenbone can run the internal vulnerability scans under Requirement 11.3.1, but the external scans under Requirement 11.3.2 must be performed by a PCI SSC Approved Scanning Vendor (ASV). Both scan types must occur at least once every three months, and both require rescans until high-risk findings are resolved. The internal side also carries two requirements that shape how Greenbone is configured: 11.3.1.1 asks for a targeted risk analysis of lower-risk vulnerabilities, and 11.3.1.2 requires authenticated scans with sufficient privileges. Both became mandatory on 31 March 2025, so a scan profile that runs unauthenticated will not satisfy the internal requirement.
Internal scans do not need a QSA or an ASV, but the tester must be qualified and independent of the systems being scanned, so the team should document who runs the scans and how they are separated from the administrators who patch the systems. Greenbone Community Edition provides the scanning engine, scheduled tasks and reports. The team must still confirm that its feed and edition cover the checks it needs, and that its scanner can reach every system in the cardholder data environment, including segments that sit behind firewalls.
The PCI SSC does not enforce compliance or impose penalties. The individual payment brands decide which entities must validate and run any enforcement programs, so the first question for the team is which brand programs apply to its acquirer relationship. Results are documented on official PCI SSC templates: a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each supported by an Attestation of Compliance. Scan reports are evidence for these documents, not a substitute for them, and certificates are not recognized as validation. Ask the assessor early which scan records they will sample and in what format.
How each PCI DSS 11.3 requirement maps to scanning tasks and configuration
This table maps each part of requirement 11.3 to the scanning work it creates and to the Greenbone settings or ASV engagement steps that support it. Read it as a checklist: the internal rows can be run with Greenbone, while the external row needs an approved scanning vendor. The 90-day maximum between scans (per PCI SSC FAQ 1087) and the March 31, 2025 effective date for 11.3.1.1 and 11.3.1.2 are the two dates to plan around.
| Requirement | What the function must do | How to configure Greenbone or the ASV engagement |
|---|---|---|
| 11.3.1 Internal scans | Run internal vulnerability scans at least once every three months, resolve high-risk and critical findings, and rescan to confirm resolution by qualified, independent testers | Create a recurring scan task in gvmd with a schedule no longer than 90 days apart, tag high and critical results for tickets, and schedule a rescan after each fix. Assign the scanning to staff independent of the systems' administrators, and confirm with your QSA how independence is judged |
| 11.3.1.1 Lower-risk findings | Address lower-risk vulnerabilities through a documented, targeted risk analysis rather than ignoring them (mandatory since March 31, 2025) | Record a risk decision for each accepted medium or low finding in the tracker, with owner, rationale, compensating control and review date. Use Greenbone overrides or notes only where they are documented in the same record |
| 11.3.1.2 Authenticated internal scans | Run internal scans with credentials that have sufficient privileges to check installed software and configuration (mandatory since March 31, 2025) | Create SSH and Windows credentials in gvmd for each target group, attach them to scan targets, and confirm in each report that the authentication status is successful. Treat unauthenticated results as incomplete until the credentials are fixed |
| 11.3.2 External scans | Run external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor, and rescan until the ASV passing criteria are met | Greenbone cannot produce this evidence. Engage an ASV, provide the list of external IP addresses in scope, schedule scans within 90 days of each other, and plan rescans with the ASV before the next assessment |
| Scan timing limit | Keep the maximum gap between quarterly scans to three months, or 90 days (PCI SSC FAQ 1087) | Set calendar reminders at 60 and 80 days, and keep the scan completion dates in the evidence folder. Ask your QSA or acquirer how they count the gap when a rescan is run |
Where Greenbone fits and where an approved scanning vendor is required
Requirement 11.3.1 calls for internal vulnerability scans at least once every three months, with high-risk and critical findings resolved and confirmed by rescans. The scans must be performed by qualified, independent testers, and an ASV is not needed for internal scans. Greenbone Community Edition can run these scans. The OpenVAS Scanner runs the vulnerability tests and is controlled through the Open Scanner Protocol, while gvmd schedules tasks, stores results in PostgreSQL and manages users. The openvas-scanner code is GPL-2.0 and gvmd is AGPL-3.0.
- Authenticated scans: Requirement 11.3.1.2 expects authenticated scanning with sufficient privileges. Confirm which credential types the team can configure for each in-scope system class.
- Installed software checks: The Notus Scanner compares installed software against known vulnerable versions during each scan, which supports authenticated coverage on hosts.
- Automation: gvmd exposes the Greenbone Management Protocol, which gvm-tools can call to schedule and export scans.
- Deployment: The Community Containers need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended.
- Feed coverage: The Community Feed excludes vulnerability tests for enterprise products, so confirm tests exist for every in-scope product before relying on a clean result.
Check that your assessor accepts the internal scan records and the qualifications of the people running them.
Requirement 11.3.2 requires external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor, with rescans until the ASV Program Guide passing criteria are met. Open-source tools, including Greenbone, do not replace this step because the scan must come from an ASV scan solution that the PCI SSC has approved. ASVs go through annual re-approval, so confirm the vendor's current status on the PCI SSC list before contracting.
- Passing criteria: PCI SSC FAQ 1152 says a passing external scan generally has no vulnerabilities scoring 4.0 or higher on CVSS, so plan remediation against that expectation.
- Rescans: Budget for rescans after fixes, because a failing external scan must be repeated until it passes.
- Timing: FAQ 1087 treats 90 days as the maximum time between quarterly scans, so schedule the next scan before the current one ages out.
- Scope agreement: Agree in writing which external IP addresses and domains the ASV will scan, and who approves changes to that list.
- Dispute handling: Ask the ASV how it handles false positives and how it documents an attestation of a scan result that you believe is incorrect.
Confirm with your ASV and your acquirer whether they expect the ASV report in the same format used for your assessment template.
Scanning only covers systems inside the scope you define, so the cardholder data environment boundary decides what Greenbone and the ASV must reach. PCI DSS applies to any system that stores, processes or transmits cardholder data or sensitive authentication data, and to systems that could affect the security of that environment. Connected networks, management consoles, jump hosts and monitoring systems can fall inside scope even when they hold no card data.
- Asset inventory: Maintain a current list of in-scope hosts, networks and cloud accounts, and reconcile it against scanner target lists each cycle.
- Segmentation tests: Where segmentation reduces scope, confirm the boundary with testing that your assessor accepts, since an unscanned network that should be in scope creates a gap.
- Internal versus external placement: A system reachable from the internet is covered by the ASV scan, while the same system should still appear in internal authenticated scans.
- Service provider responsibilities: If a third party hosts in-scope systems, confirm which party performs and records each scan.
- Payment brand rules: Visa and other payment brands set validation levels, so confirm the level that applies to your organization.
Ask your QSA or the assessor to review the scope diagram and the scanner target list together before the first scan cycle.
A scanner is only as useful as the tests it runs. Greenbone's Community Feed is free, but Greenbone states that Community Feed releases exclude vulnerability tests for enterprise products. A scan of a system that depends on those products can therefore report no findings when the test does not exist, which would be a false assurance during an assessment. Greenbone's Enterprise Feed is the commercial alternative for broader coverage.
- Feed comparison: Compare each in-scope product family against the Community Feed and the Enterprise Feed before you sign off on coverage.
- Data loading: In the containers, dedicated data containers load vulnerability tests, Notus data, CVE and CPE data and CERT-Bund advisories into volumes at startup, so confirm that the update job runs and that the data date is recorded.
- Gaps in writing: Document products that the scanner cannot test and the compensating checks you use for them.
- Versions: Record the scanner and feed versions used for each scan, because an assessor may ask which data was current on the scan date.
- Vendor questions: Ask the scanner vendor which enterprise product tests are excluded from the free feed.
Ask your implementation partner for a coverage matrix that maps in-scope products to the feed that tests them.
Which open-source platforms fit PCI DSS scanning and tracking
PCI DSS 11.3 splits work between internal scans you run yourself, external scans from an Approved Scanning Vendor, and the records that prove remediation. The platforms below cover the internal scanning, container and component sources, and central tracking that feed that evidence, while the external scan still goes to an ASV.
Greenbone Community for authenticated internal scans
Greenbone Community Edition runs vulnerability tests against cardholder data environment hosts and is managed through gvmd, which stores results in PostgreSQL and runs scheduled tasks. Requirement 11.3.1.2 expects internal scans to be authenticated with sufficient privileges, so check that the scan credentials cover the operating systems, databases and network devices in scope. Community Feed releases exclude some enterprise product tests, so confirm feed coverage against your inventory before you rely on it for a scan record.
Trivy for container and image findings
Trivy scans container images, file systems and infrastructure definitions for known vulnerabilities, which helps when cardholder workloads run in containers that a host scan does not reach. Build the scan into CI and the registry so that base images and application layers are checked before deployment. Confirm with your assessor how image scan results will be presented as part of the 11.3.1 evidence, because a container scan does not replace the host scan.
Dependency-Track for component tracking
Dependency-Track tracks the software components in your applications and matches them against known vulnerabilities over time, so a new CVE can be traced to affected payment applications without a fresh scan. This helps teams show that third-party components in the cardholder data environment are monitored between quarterly scans. Confirm that the SBOMs feeding it are produced for every payment application release.
DefectDojo for deduplication and remediation tracking
DefectDojo imports OpenVAS and Greenbone reports, and also Tenable, Qualys and Nexpose exports, then deduplicates findings and tracks them to closure, which supports the rescan and resolution records that 11.3.1 asks for. The open-source edition is BSD-3-Clause, installs with Docker Compose and uses local accounts. According to its README, SSO with SAML, OIDC or OAuth, LDAP and MFA are DefectDojo Pro features, so confirm how administrator access will be controlled before the tool holds cardholder-environment findings.
Wazuh as a complementary agent source
Wazuh is an open source security platform with unified XDR and SIEM capabilities that uses agents on endpoints and servers. Its agent telemetry can help you spot unauthorized software and configuration drift between scheduled scans, but it does not replace an authenticated scan for the requirement. Confirm with your QSA whether agent data will be accepted as supporting evidence in your assessment scope.
How the quarterly scanning cycle runs from scope to passing evidence
This sequence turns the cardholder data environment boundary into a repeatable set of internal and external scans, with each rescan and vendor scan tied to a record an assessor can examine. Its output is a set of passing or remediated scan results, plus the attestation evidence that goes into the assessment.
Confirm CDE scope and asset inventory
The compliance lead and network team define the cardholder data environment and every system that connects to it, including hosts, network devices, containers and cloud resources. Scanning covers only what is in this inventory, so gaps here become gaps in coverage. The step is complete when the inventory is signed off and each in-scope asset has an owner and a network location that the scanner can reach. Ask your QSA or assessor to confirm the scope boundary before scanning starts.
Deploy Greenbone Community Containers
The platform team deploys the Greenbone Community Containers on a management host inside the network segment that can reach in-scope systems, orchestrated with Docker Compose. The minimum is 2 CPU cores, 4 GB of RAM and 20 GB of storage, and the documentation recommends 4 cores, 8 GB and 60 GB. The data containers load vulnerability tests, Notus data and CVE and CPE data into volumes at startup, so the step is complete when the feed loads finish and a test scan against one known host returns results.
Configure authenticated scan credentials
The security engineer creates scan credentials with sufficient privileges on in-scope hosts and assigns them to scan targets. Authenticated scanning is a mandatory expectation for internal scans under the current version of the standard, so unauthenticated results alone will not support the internal requirement. The step is complete when a sample host reports installed packages in the results, which confirms that the credential works. Record which accounts were used and who approved them.
Schedule quarterly scan tasks
The engineer creates scheduled tasks in gvmd for internal scans and sets the interval so that consecutive scans fall well inside the 90-day maximum that the standard's FAQ describes. Schedules should leave margin for failed or delayed runs, so teams usually set a shorter cadence than the maximum. The step is complete when the schedule is saved, a first full run is recorded, and the next run date is in the change calendar. Keep the schedule definition as evidence of the policy.
Triage and risk-rank lower findings
The security team reviews each result, removes false positives with written justification, and ranks the remaining findings by severity and exposure. Findings rated high and critical go into remediation with an owner and a target date. Lower-severity findings go through a documented risk analysis, which the standard now requires as a targeted risk analysis for lower-risk vulnerabilities. The step is complete when every finding has a recorded status, owner and decision, and exported reports are stored with the scan records.
Remediate and rescan until clear
System owners patch, reconfigure or document compensating measures for high and critical findings, and the scanning team reruns the scan against those targets. The cycle repeats until no high or critical vulnerabilities remain on the scanned systems. The step is complete when the final rescan shows the findings closed, and each closure is linked to a change record or ticket. Keep the failed scans as well, since assessors compare the sequence of scan results.
Engage an ASV for external scans
External systems need scans by a PCI SSC Approved Scanning Vendor, which Greenbone Community cannot replace for this requirement. The team confirms the vendor is on the current PCI SSC ASV list, provides its scope of external IP addresses and domains, and reviews the results for any vulnerability at or above the passing threshold. Rescans run through the ASV until its passing criteria are met. The step is complete when the vendor issues a passing scan report, and the team has checked the list of approved vendors before signing.
Assemble the AOC evidence package
The compliance lead collects the scan reports, schedules, credential records, risk analyses, remediation tickets, rescan results and ASV reports into one evidence folder mapped to the requirement. The assessor then uses these records alongside the Attestation of Compliance or Report on Compliance that the organization submits. The step is complete when an internal reviewer can trace one high-risk finding from detection through closure using only the stored records. Ask your QSA to confirm which artifacts they expect before the package is final.
Evidence assessors ask for and which component produces it
This table maps each piece of evidence a QSA or ASV-facing team typically requests for Requirement 11.3 to the component that generates it. Use it to plan where records live before an assessment, and confirm each item's format with your assessor early.
| Evidence item | Source component | What to confirm |
|---|---|---|
| Internal scan reports showing authenticated scans | Greenbone (gvmd reports) with credentialed scan targets | Credentials have sufficient privileges on every in-scope host, and the report records the authentication status per target |
| Scan schedules showing at least quarterly cadence | Greenbone scheduled tasks, exported from gvmd | Schedules cover all in-scope networks and the maximum interval between scans stays within 90 days |
| Rescan records for high and critical findings | Greenbone rescan results, tracked as tasks in DefectDojo | Each high and critical finding has a dated rescan that shows it resolved or a documented exception |
| Risk analysis records for lower-risk findings (11.3.1.1) | DefectDojo findings with risk acceptance or targeted risk analysis notes | Your assessor accepts the format and the analysis is dated, owned and reviewed |
| ASV passing scan reports for external systems | PCI SSC Approved Scanning Vendor, not Greenbone | Report is from an ASV on the PCI SSC list, passes the ASV Program Guide criteria and covers all external IPs |
| Remediation tickets linked to findings | DefectDojo findings linked to the ticketing system | Tickets show owner, due date, fix date and the rescan that confirmed closure |
| Signed Attestation of Compliance (AOC) | Issued from the ROC by a Qualified Security Assessor or from the SAQ process | The AOC is signed and the assessor or merchant confirms the scope matches the scan records |
| Confirmation that certificates are not validation | Not produced by any tool; policy and assessor communication | Scan vendor certificates or badges are not accepted as proof of compliance (PCI SSC FAQ 1220) |
What scanning tooling alone does not satisfy under PCI DSS
Greenbone can run the internal scans that Requirement 11.3.1 describes, but a scan result is only one piece of evidence. The cards below cover the external scan obligation, the assessment itself, the documentation a customized approach demands, and the version and tester questions that shape how the evidence is judged.
External scans still need an ASV
Requirement 11.3.2 requires external vulnerability scans at least once every three months by a PCI SSC Approved Scanning Vendor. An open-source scanner run by your team does not replace that scan, even when its results are accurate. Confirm with your acquirer or the payment brand which external systems are in scope, and schedule ASV scans against the same boundary your internal scans use. Rescans continue until the ASV Program Guide passing criteria are met.
Tooling does not perform the assessment
Greenbone produces scan data, but it does not decide whether your environment meets PCI DSS. A Qualified Security Assessor completes the Report on Compliance, or you complete a Self-Assessment Questionnaire with its Attestation of Compliance, and the assessor reviews the scan records, configurations and exceptions behind each answer. Budget for that assessment as a separate line item, and ask the assessor early which scan reports and dates they will sample.
Customized approach needs documented objectives
The customized approach lets an entity meet a requirement's stated objective in a different way, but only for entities with robust security and risk management. Using it for vulnerability scanning means documenting the objective, the controls used, a targeted risk analysis and evidence that the controls still meet the objective. Standard scanning evidence alone will not support that claim. Confirm with your QSA whether this path is open to you before changing the approach.
Community Feed coverage limits
The Greenbone Community Feed is free, but release notes state that it excludes vulnerability tests for enterprise products. If your cardholder data environment runs commercial products that appear only in the Enterprise Feed, those hosts may not receive full test coverage. Before relying on scan results for Requirement 11.3.1, compare your product inventory with the feed's coverage and document any gaps and the compensating checks you run.
Authenticated scans need qualified testers
Requirement 11.3.1 calls for internal scans performed by qualified, independent testers, and Requirement 11.3.1.2 requires authenticated scans with sufficient privileges. Your own administrators can run scans, but they must be qualified and independent of the systems they test. Keep credential handling, scan configurations and tester qualifications in writing, and ensure scan accounts have the privileges the requirement assumes.
PCI DSS v4.0.1 is the active version
PCI DSS v4.0.1 is the only active version, following the retirement of v4.0 on 31 December 2024. The PCI SSC ran a request for comments on v4.0.1 to begin the next iteration, but as of October 2026 it has announced no release date for a new version. Map your scanning procedures to v4.0.1 wording now, and check the PCI SSC website before each assessment cycle for any change to the standard or its supporting templates.
Questions buyers ask before hiring help with PCI DSS scanning
Does Greenbone alone satisfy PCI DSS requirement 11.3?
No. Greenbone can cover the internal side of requirement 11.3.1, but the external scans under requirement 11.3.2 must be performed by a PCI SSC Approved Scanning Vendor (ASV). Internal scans need to run at least once every three months, be authenticated with sufficient privileges, and be rescanned until high-risk and critical findings are resolved. A QSA or ASV is not required for internal scans, so your own qualified, independent staff can run them. Confirm with your assessor how they will evidence scan coverage, credential use and rescan results, because the scan reports are only part of the record.
What drives the cost of PCI DSS vulnerability scanning?
Cost comes from four components, each paid to a different party. Scanner hosting is your infrastructure cost for the Greenbone containers, which need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage per the Greenbone Community docs, with 4 cores, 8 GB and 60 GB recommended. Credential setup and triage are labor costs that recur each quarter. ASV fees are set by the approved vendor and are quoted separately, so ask for them in writing. Remediation effort depends on how many findings are real and how many systems share a fix. Ask any partner to split its quote into one-time setup and recurring quarterly work.
How long does the first PCI DSS scanning cycle take?
No duration has been fixed for this work, so confirm the timeline with any implementation partner against your written scope. The first cycle usually takes longer than later ones because it includes scanner deployment, feed loading, scan policy design, authenticated credential setup, and a baseline review of findings. The schedule depends on the number of in-scope hosts, how quickly your team provides asset lists and access, and how many high-risk findings need remediation before a passing rescan. Ask the partner to show the milestones, dependencies and what you must deliver at each step.
What must our team provide before a scanning engagement starts?
Three inputs shape the scope and accuracy of the scans. First, a current asset inventory of in-scope systems, with IP ranges, hostnames and owners. Second, a cardholder data environment (CDE) diagram that shows which systems store, process or transmit cardholder data and which connected systems could affect their security. Third, authenticated scan credentials with sufficient privileges on hosts, databases and network devices where you require authenticated scanning. You will also need a named owner for remediation tickets and a window for scans that does not disrupt payment operations. Your partner should confirm each item in the written scope.
Can our own security team run PCI DSS internal scans without outside help?
Yes, if the team has the skills and independence the standard expects. Internal scans under requirement 11.3.1 do not require a QSA or ASV, so an internal team can deploy Greenbone, configure authenticated scans, triage results and keep rescan records. The harder parts are external scanning, which must go through an ASV, and the evidence trail an assessor will sample. Teams often find that triage time, feed updates and remediation tracking consume more hours than the scan itself. Be honest about capacity, and consider a partner for setup, documentation or quarterly support if internal staff cannot maintain the cycle.
Do SAQ A merchants need an ASV scan?
It depends on the questionnaire and the environment, so confirm it with your acquirer or assessor. PCI SSC FAQ 1604 addresses ASV scans in SAQ A, and the answer depends on how your payment page and any outsourced elements are built. Merchants that outsource all cardholder data handling still need to review which systems remain in their own scope. Start by documenting your SAQ type, your CDE boundary and any connected web components. Then ask your acquirer which scans they require for your validation level, because the payment brands set those expectations.
Who decides which merchants and service providers must validate PCI DSS?
The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. The PCI Security Standards Council owns and maintains the standard, but it does not enforce compliance or impose penalties, according to PCI SSC FAQs 1004 and 1015. Validation levels and reporting requirements are usually set by your acquirer and payment brand rules. Visa publishes compliance validation levels for merchants and service providers, and the same question should be confirmed with your acquirer before you buy scanning services.
Does a passing scan mean the environment is compliant?
No. A passing external scan generally means no vulnerabilities scoring 4.0 or higher on CVSS, according to PCI SSC FAQ 1152, but it does not prove the whole standard is met. Internal scans, authenticated checks, remediation records and the assessment itself are separate requirements. Assessors look for evidence that scans happened at least every three months, that high-risk findings were fixed and rescanned, and that results were reviewed. Ask your assessor which artifacts they will request before choosing a scanning approach.
How DeployOpen scopes the PCI scanning work
The sequence moves from a written scope to a running, authenticated internal scanning program and a set of records that your QSA and ASV can review. It separates what DeployOpen builds and documents from what an approved scanning vendor must still perform.
Confirm the cardholder data environment scope
DeployOpen reviews your network diagrams, asset inventories and data flow records with your QSA or internal assessment lead to define which systems sit inside the cardholder data environment and which connect to it. The output is a written scope document listing in-scope IP ranges, hosts, containers and cloud accounts, plus the systems excluded and the reasons. Work does not start until your team has signed off on that list.
Agree deliverables and responsibilities in writing
The fixed-scope proposal names each deliverable, who performs it, and which parts remain with your team or an approved scanning vendor. It states that the internal Greenbone program supports Requirement 11.3.1, while external scans under Requirement 11.3.2 must be run by a PCI SSC Approved Scanning Vendor. Confirm the commercial terms, timelines and any ASV engagement with the vendor before kickoff.
Deploy the self-hosted Greenbone stack
DeployOpen installs the Greenbone Community Containers inside your own cloud account, data center or segment that can reach the in-scope internal ranges, using the Docker Compose orchestration described in the project documentation. Feed data is loaded by the dedicated data containers. Confirm that the host meets the documented minimum resources and that the feed licensing matches what you intend to use. The output is a running stack with a documented build, access controls and a backup plan.
Configure authenticated scan profiles
Engineers create scan targets, credentials and schedules that run authenticated scans with privileges sufficient to read configuration and installed software, which Requirement 11.3.1.2 makes mandatory. Credentials are stored in the Greenbone configuration and access is limited to named operators. The check is a test scan against a sample of in-scope hosts where the results show the installed package checks, confirming the scan is not running unauthenticated.
Run testing scans and validate findings
DeployOpen runs test scans against the agreed scope, reviews the results with your team and checks for false positives and gaps in coverage. Where a result is disputed, the engineer documents the evidence. Scan safety settings are reviewed before production runs so that fragile systems are handled under agreed rules. The output is a validated baseline report and a list of unresolved items, sorted by severity, that your team can act on.
Set the quarterly scan and rescan schedule
Scheduled tasks are configured so internal scans run at least once every three months, with rescans after remediation of high-risk and critical findings until they are resolved. The schedule, the owners of each task and the escalation path for missed runs are written into the operating procedure. Confirm the schedule with your QSA, since the policy must match what the assessor sees in the records.
Prepare the evidence pack for assessment
DeployOpen compiles the scope document, configuration records, scan reports, rescan results, exception records and the targeted risk analysis for lower-risk findings into an evidence pack organized by requirement. Your QSA or internal assessor decides what is sufficient. DeployOpen prepares the evidence but does not issue Reports on Compliance, Attestations of Compliance or any certification, and it does not replace the ASV scans required for external systems.
How DeployOpen delivers self-hosted PCI scanning and evidence
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source scanning inside your own infrastructure, including Greenbone for internal scans. We prepare the scanning systems, controls and evidence for your assessment, while the ASV, QSA and your payment brand decide what they accept.
How we scope
- Engagements are fixed-scope, with scanner coverage, targets and deliverables agreed in writing before work starts.
- We map which in-scope systems need internal authenticated scans and which external systems must go to an approved scanning vendor.
- Scope records which assets, credentials and network segments the scanners reach, and who owns each.
How we build
- We deploy the Greenbone Community Containers in your cloud account, data center or air-gapped network, sized to your target count.
- We configure authenticated scan credentials with the privileges needed for internal scans under Requirement 11.3.1.2.
- We set scan schedules, feed update routines and a scan safety profile agreed with your operations team before the first run.
How we hand over
- We document scan configuration, scheduling, rescan rules and the process for high-risk and critical findings.
- We connect results to your ticketing or tracking workflow, such as DefectDojo, and deliver reports that show scan dates and resolutions.
- We hand over runbooks and an evidence index mapping each scan record to the requirement it supports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover feed updates, scanner upgrades, rescan verification and preparation for each quarterly cycle.
- We confirm with your QSA or ASV which evidence they accept, and adjust the reports and records before each assessment.
Sources and further reading
- PCI DSS v4.0 Self-Assessment Questionnaire D for Service Providers ↗
- PCI SSC FAQ 1087: quarterly scan timing ↗
- PCI SSC: Approved Scanning Vendors ↗
- PCI SSC blog: Resource Guide on vulnerability scans and ASVs ↗
- Greenbone Community docs: Architecture and background ↗
- Greenbone Community docs: Community containers ↗
