What PCI DSS 6.3 vulnerability management requires and why assessors focus on it
When a QSA or internal assessor reviews Requirement 6.3, they will ask three things: how your team learns about new vulnerabilities, how it decides which ones are urgent, and how quickly it installs fixes. Requirement 6.3 covers all of these for every piece of software in scope. It asks you to monitor industry sources and assign risk rankings to new vulnerabilities, to keep an inventory of bespoke and custom software and its third-party components, and to install security patches and updates. In PCI DSS v4.0.1, the 30-day installation timeframe applies to patches for critical vulnerabilities, and other patches are installed within a timeframe your entity sets and can justify.
The risk is straightforward. Attackers exploit known flaws in payment software and libraries faster than many teams can find and fix them, and a single unpatched component in the cardholder data environment can expose stored or transmitted account data. The difficulty usually sits in three places: inventory gaps, where nobody can say which libraries, containers or appliances are running; unclear ownership of third-party components, where the vendor, the development team and operations each assume another party tracks updates; and scanners that do not read vendor advisories. The vulnerability scans required under Requirement 11 do not replace monitoring of industry sources, a distinction the SAQ D guidance makes explicit.
Before your next assessment, confirm three things. Name an owner for each source you monitor, including vendor security bulletins and advisories for commercial components. Check that your software inventory covers custom code and third-party components, not only operating systems. Write down the timeframe you use for non-critical patches and the reasoning behind it, so the assessor can trace each decision. Open-source tools such as OWASP Dependency-Track can help you match components against known vulnerabilities, but the policy, the rankings and the evidence of action remain your responsibility.
Which systems, software and teams PCI DSS 6.3 covers
Requirement 6.3 applies to every software component that touches the cardholder data environment, not only the code your team writes. The scope you can defend is the CDE scope you have validated, so the cards below follow that boundary and name the teams that own each part of it.
System components in the CDE
Every system component inside the cardholder data environment, along with systems that connect to it or could affect its security, falls under the 6.3 inventory and patch process. This includes operating systems, databases, middleware, network appliances and management consoles. Check that your asset list matches the boundary in your latest scope validation, and that each item has a named owner who receives vulnerability findings.
Bespoke and custom software
Software your organization builds or has built for it, including payment applications, APIs, batch jobs and internal tools that handle account data, must be inventoried under 6.3.2. The inventory should list each application, its version, its owner and its dependencies. Without it, a vulnerability disclosed in a library cannot be traced to the code that uses it.
Third-party and open-source components
Libraries, frameworks and packages inside payment applications are part of the same inventory, including transitive dependencies that developers never named directly. Software bills of materials in CycloneDX or SPDX form make these visible. Ask each development team to show which components are pulled in at build time and which are bundled into release artifacts.
Containers and images
Container base images, application layers and orchestration components are software with their own vulnerabilities and update cycles. An image that was clean at build time can become vulnerable when a new advisory appears, so images in registries and running clusters both need review. Confirm whether your image registry is in the CDE scope and who rebuilds images when a base layer is patched.
Vendors that supply software or hosting
Software vendors, managed hosting providers and cloud platforms whose products sit in the payment flow must be monitored for security advisories, because 6.3.1 requires identifying vulnerabilities from industry sources. Build a register of these vendors with the products and versions you use, and confirm how each one notifies customers of security issues. Vendor advisories often arrive before public vulnerability feeds list them.
Teams that own each layer
Infrastructure, application development, platform engineering and the third parties that operate hosted components each own part of the work. Assign one accountable owner for each system component and software inventory entry, and write down who monitors sources, who ranks risk and who installs patches. Gaps usually appear at the handoffs between these teams, so review the register at each change to scope.
How a QSA tests PCI DSS 6.3 vulnerability management
This table compares the three sub-requirements of Requirement 6.3 across how a Qualified Security Assessor (QSA) tests them, the evidence they request and the findings that appear most often. Read each row as a checklist: the evidence column shows what to have ready before fieldwork, and the findings column shows where assessments usually stall.
| Sub-requirement | How a QSA tests it | Evidence requested | Common findings |
|---|---|---|---|
| 6.3.1 Source monitoring and risk ranking | Confirms named industry sources are monitored, then samples recent vulnerabilities and checks that each received a risk ranking. Scan results alone are not treated as source monitoring. | Documented list of monitored sources, feed or alert records with dates, and the ranking method and rankings assigned to sampled items. | No defined sources, scan output used as the only monitoring, or risk rankings that carry no date or reviewer. |
| 6.3.2 Software and component inventory | Compares the inventory against the in-scope environment and against code or build artifacts, looking for bespoke software and third-party components that are missing. | Current inventory of bespoke and custom software and third-party components, with versions, owners and the date last reconciled. | Missing inventory entries for libraries or containers, components listed without versions, or an inventory not refreshed after releases. |
| 6.3.3 Security patch installation | Samples patches and critical vulnerabilities, then compares release, identification and installation dates against the critical vulnerability timeframe. Late items need documented justification. | Patch records with identification and install dates, risk rankings for each sampled item, and written justification or approved exceptions for late installs. | Critical patches installed after the timeframe with no documented justification, or patch dates that cannot be traced to a vulnerability record. |
Implementing PCI DSS 6.3 in six steps
This sequence turns Requirement 6.3 from a policy statement into a working cycle: know what software you run, rank what is found, track what arrives from outside, and patch on timeframes you can defend. Each step leaves a record that an assessor can sample.
Define the cardholder data environment and its sources
Start by listing the systems inside the cardholder data environment (CDE) and every system that could affect its security. For each one, name the sources you will watch for vulnerability information, such as software vendors, open-source project advisories, hosting providers and the operating system maintainers. Record the owner of each source and how it reaches your team. The output is a scoped source register that states which systems and which feeds 6.3 covers. An assessor can compare it against your network and data-flow diagrams to confirm nothing is missing.
Build the software and component inventory
Create an inventory of bespoke and custom software and of the third-party components each one uses, including operating system packages, libraries and containers. Generate software bills of materials (SBOMs) where you can, because they make component lists repeatable and checkable instead of hand-written. Tools such as Trivy can produce package lists from a target, and OWASP Dependency-Track can ingest CycloneDX SBOMs and keep component records current. Assign an owner to each entry and set a review point for new releases. The output is an inventory with version numbers and owners that matches what runs in production.
Document a risk-ranking method you own
Write a method that assigns each newly identified vulnerability a risk ranking based on your own environment, such as whether the affected component is internet-facing, handles cardholder data, or is reachable from a compromised system. PCI SSC FAQ 1597 confirms that you may evaluate external rankings and assign your own, so record how you weigh vendor scores against your context. Have the method approved by the people accountable for the CDE and keep the version history. The output is an approved ranking procedure with worked examples that an assessor can follow to a specific ranking decision.
Connect advisory sources to a tracking system
Route the sources from step one into a single tracking system so that every vulnerability has one record, one owner and one status. DefectDojo can import findings from many scanner report formats and deduplicate them, which helps when several tools report the same issue. Greenbone Community Edition can supply scan results for the same record set. Confirm which report formats and integrations your chosen tools support before you commit, because support differs by version. The output is a live findings register with timestamps showing when each item was identified, ranked and assigned. Note that vulnerability scans alone do not satisfy the source monitoring the standard asks for, so keep advisory feeds in the register as well.
Set patch timeframes and link them to change records
Define two timeframes: one for critical vulnerabilities, which under PCI DSS v4.0.1 must be installed within one month, and one for other patches, which you set and justify yourself. Write the criteria that decide what counts as critical in your environment, and state how each patch moves through your change process. Every patch should reference a change record that shows approval, testing and the install date, which ties 6.3.3 to the change management work in 6.5. The output is a patch standard with the two timeframes and a sample of closed tickets linking findings to changes. Confirm your timeframes with your QSA before the assessment, since the approach must meet the requirement as written.
Run the first review cycle and record results
Run one complete cycle from source intake through ranking, patching and closure, then review the results with the owners of the CDE. Check whether every inventory item has a current owner, whether each critical item met its timeframe or has a documented exception, and whether any advisory source produced nothing. Record the findings of the review, the corrective actions, and the date each action closes. The output is a signed review record and an updated register that shows the process working end to end. Assessors typically sample a few findings from start to finish, so make sure one review file can trace a single vulnerability through all five earlier steps.
Open-source tools that produce 6.3 evidence
Requirement 6.3 turns on three records: where vulnerability information came from, which software and components exist, and when patches were installed. The four tools below can hold parts of that evidence, but each one records or organizes information only. Your team still owns the risk ranking and the patch decision, and you should confirm every capability in your own environment before an assessor reviews it.
DefectDojo for findings
DefectDojo imports and reimports findings from more than 500 security tool report formats through its UI or API, and it includes a generic findings import for other sources. It deduplicates findings using per-tool hashcode fields, which keeps one vulnerability from appearing as many tickets. For 6.3.1, the record shows which sources were monitored and how each finding was reviewed and ranked by your team. Confirm that the tools you run have an importer, since the list is not the same as a guarantee for your scanner version. The license is BSD-3-Clause, which permits commercial use with attribution.
Greenbone for scan records
Greenbone Community Edition (OpenVAS) runs scan tasks, stores results in PostgreSQL, and manages users and permissions through the gvmd service, with results reviewed in the Greenbone Security Assistant web interface. Scheduled scans and stored results give an assessor a dated history of what was checked and when. Note that vulnerability scanning does not replace source monitoring for 6.3.1, because the SAQ D note says monitoring sources is not achieved by the scans required in 11.3.1 and 11.3.2. The license is AGPL-3.0-or-later, so confirm with counsel what obligations apply if you modify and distribute it or offer it over a network.
Dependency-Track for components
OWASP Dependency-Track consumes and produces CycloneDX SBOMs and VEX, and it flags components with known vulnerabilities, outdated versions, or modified code. That gives you the component inventory 6.3.2 requires for bespoke and custom software and its third-party parts. Each flagged component should also carry a recorded decision, such as an upgrade plan or a documented exception, which Dependency-Track can hold but does not make for you. Its license tracking uses SPDX license IDs, so it can support license review as well. The project is Apache-2.0. Check that your inventory covers every application in scope, not only the ones your team has already registered.
Trivy for SBOM generation
Trivy identifies OS packages and software dependencies in a target and can output them as a software bill of materials. It can also scan an existing SBOM, so teams can generate inventory from images, file systems, or repositories and check it against known vulnerabilities. Its output feeds the component inventory in 6.3.2 and the patch planning in 6.3.3, where critical patches have a one-month installation timeframe under v4.0.1. Run Trivy in the build pipeline and on deployed systems, since an SBOM generated only at build time can drift from what is running. Trivy is Apache-2.0 licensed. Confirm its database update schedule in your environment, because scan results depend on it.
What PCI DSS 6.3 costs in money and effort
This table breaks down the cost components of meeting Requirement 6.3, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written scope and to compare itemized quotes line by line. No figures are given because none are supplied; request them from each provider and assessor.
| Cost component | One-time or recurring | What drives it up | What keeps it down |
|---|---|---|---|
| Tooling and licenses (open-source scanners, SBOM and findings tools) | Recurring (hosting and maintenance), with a one-time setup | Number of hosts, applications and pipelines to cover; ask the provider to itemize hosting, storage and upgrade effort separately from any paid support | Use open-source tools with no license fee, sized to the environment; confirm licensing terms for any add-on or hosted component |
| Engineering time to build the software and component inventory (6.3.2) | One-time build, recurring upkeep | Number of bespoke applications, third-party components and transitive dependencies; poor build hygiene and undocumented software | Automated SBOM generation in CI/CD so each build updates the inventory without manual lists |
| Engineering time for the patch pipeline (6.3.3) | One-time build, recurring operation | Number of production components, release frequency of vendors, and how many patches need out-of-cycle testing | Standard patch workflow with pre-approved test paths; a defined, documented timeframe for non-critical patches as the entity sets it |
| Ongoing time to review advisories and rank findings (6.3.1) | Recurring, usually staff time | Number of third-party sources monitored, volume of new advisories, and number of third parties whose products you run | Shared written ranking criteria applied to every source, so analysts do not re-decide severity for each finding |
| Deduplication and triage of scanner output | Recurring | Number of scanners in use and overlap between their findings | Central findings platform with deduplication, so each vulnerability is triaged once |
| External scanning or independent review (if used) | Recurring or per engagement | Scope size, number of applications and hosts, and frequency of review | Written scope limited to in-scope components; ask for an itemized quote per service and its deliverables |
| Assessor sampling during the audit | Recurring, once per assessment cycle | Number of components, patch cycles and advisories the assessor samples, and gaps in records | Keep the inventory, advisory log and patch records current so the assessor can sample from them directly |
Which evidence passes a 6.3 assessment and how to keep it current
An assessor testing Requirement 6.3 looks for records that show what software you run, how you rank its vulnerabilities, where you learned about new threats, and how fixes reached production. The five artifacts below connect those steps, and each needs a review rhythm and retained history so an assessor can sample any past period, not only the current one.
Dated software and component inventory
This is the record of bespoke and custom software and its third-party components that 6.3.2 requires, and it is the base for every other artifact. Keep it dated, with the version, owner and environment for each item. Generate it from SBOM tooling such as OWASP Dependency-Track, which consumes and produces CycloneDX SBOMs, or Trivy, which can produce an SBOM from a target. Review it at each release and store each export so you can show the inventory as it stood on any sampled date. An inventory that is not dated cannot prove coverage for a past period.
Documented risk-ranking method and rankings
Under 6.3.1 you must identify vulnerabilities from industry sources and assign each a risk ranking. Write down the method, including the factors you weigh, who approves rankings and how environment context changes them. PCI SSC FAQ 1597 confirms you may evaluate external rankings and assign your own, so record where you agreed or overrode a vendor score and why. Review the method annually and keep superseded versions so an assessor can see which method applied at the time of a given ranking.
Source monitoring log
This log shows which vulnerability advisories and feeds you checked, when you checked them and who reviewed the results. The SAQ D note to 6.3.1 states that the vulnerability scans required under 11.3.1 and 11.3.2 do not satisfy source monitoring, so scan reports alone will not pass this artifact. Record each source, the check date, the findings triaged and any gaps. Keep the log continuous with no silent periods, and retain past entries for sampling. Tools such as DefectDojo, which imports findings from more than 500 tool report formats, can hold triage history in one place.
Patch tickets linked to change records
Each patch should trace from the vulnerability record to a ticket, then to the change record that deployed it, with the install date on both. Under 6.3.3 as revised in v4.0.1, the one-month timeframe applies to critical vulnerability patches, while other patches follow a timeframe you set. Confirm that your change process (see 6.5) links to this trail. Export ticket and change data monthly and keep it, because an assessor will pick dates from the assessment period and compare them to ranking dates.
Approved exceptions for non-critical items
When you defer a non-critical patch, the deferral needs a record: the vulnerability, the reason, the compensating measure, the approver and an expiry or review date. Because v4.0.1 lets you set timeframes for non-critical patches, your own documented timeframe becomes the test, so exceptions beyond it need sign-off. Review open exceptions at each risk review and close them when the patch lands. Keep closed exceptions with their dates so an assessor can see that deferrals were controlled, not forgotten.
Who owns 6.3 in-house, with a partner and with the assessor
Your organization owns Requirement 6.3 in full. The standard expects the entity to identify vulnerabilities, assign risk rankings and decide how and when patches are installed, and those judgments cannot be handed to a vendor or consultant. The people who run the program must be able to explain why a given vulnerability was ranked as it was and why a patch was deferred.
- Risk-ranking method: Define how your environment translates a vendor severity or an external rating into a ranking that reflects your systems, data and exposure. PCI SSC FAQ 1597 confirms you may evaluate external rankings and assign your own.
- Software inventory ownership: Maintain the list of bespoke and custom software and third-party components that 6.3.2 requires, and assign an owner to each entry.
- Patch decisions: Decide which critical patches meet the one-month timeframe, and set the timeframe for other patches, which v4.0.1 leaves to the entity.
- Risk acceptance: Record who approves deferrals and compensating measures, and at what level of seniority.
- Records: Keep the tickets, approvals, scan results and dates that show the program runs as written.
Check that each decision has a named owner and a dated record that someone outside the team could follow.
An implementation partner can do the engineering work that makes the program repeatable. Typical work includes connecting open-source tools to your sources, automating the software bill of materials, and preparing evidence samples. The partner prepares systems and evidence; it does not set your rankings, choose your patch timeframes or accept your risks.
- Inventory pipeline: Build the process that generates and updates inventories from build systems and container images, for example by producing SBOMs with a tool such as Trivy and loading them into OWASP Dependency-Track.
- Tool setup: Install and configure the scanning and tracking tools, such as Greenbone Community Edition and DefectDojo, and connect their outputs so findings land in one queue.
- Procedures: Draft the written procedures for triage, ranking and patching, which your team reviews and approves.
- Evidence preparation: Gather sample tickets, scan reports and SBOM exports so your team can show the assessor how the process runs.
- Boundaries: Keep consulting separate from the assessment. The partner must not perform the validation that the same engagement relies on.
Confirm in the written scope which deliverables the partner owns, which your staff must operate after handover, and who maintains the tools after the engagement ends.
The QSA or internal security assessor tests whether Requirement 6.3 is in place and documents the result in the Report on Compliance or the Attestation of Compliance, depending on the validation path. The assessor tests controls; it does not design them. An independent assessor must keep enough distance from any consulting work to give an objective opinion.
- Sampling: Expect the assessor to select vulnerabilities, custom components and patches and trace each one from discovery to closure.
- Ranking review: Expect questions on how the risk-ranking method was chosen and whether it reflects your environment.
- Inventory completeness: Expect the assessor to compare the inventory against the systems and code in scope to check for gaps.
- Monitoring evidence: The SAQ D note makes clear that scanning under 11.3.1 and 11.3.2 does not replace monitoring industry sources, so the assessor will look for that separately.
- Report: Only the assessor issues the ROC or AOC. Certificates from consultants are not accepted as validation.
Before engaging an assessor, confirm whether the validation is a QSA-led ROC or a self-assessment, and ask how the firm separates its assessment work from any consulting it has provided.
Most organizations outsource the mechanical parts of 6.3 and keep the judgment internal. The useful question is not whether a task can be outsourced but whether the person accepting the outcome can explain it. Tooling and evidence work recurs, so it is often retained support, while ranking and risk decisions are one-time policy work that stays with staff.
- Usually outsourced: Tool installation, SBOM automation, pipeline integration and evidence packaging.
- Usually shared: Procedure drafting, where the partner writes and your team approves and adopts the text.
- Should stay internal: Risk rankings, patch timeframes for non-critical items, risk acceptance and ownership of each inventory entry.
- Recurring work: Tool upgrades, feed updates and keeping inventories current as code and dependencies change, which drive ongoing cost.
- Cost drivers: The number of applications, the number of components per application and how many environments feed the inventory.
When requesting a quote, ask the provider to list each deliverable, the owner after handover and the work that recurs.
Common gaps that fail PCI DSS 6.3 and how to close them
Most 6.3 findings come from processes that exist on paper but leave no dated record. The six gaps below cover the inventory, source monitoring, risk ranking, critical patching and non-critical patching that an assessor will ask to see. Each card names one closing action and the evidence it produces.
No inventory of components inside custom apps
Teams often track their bespoke applications but not the third-party libraries, frameworks and container base images those applications pull in. Requirement 6.3.2 expects an inventory covering both bespoke and custom software and third-party components. Close the gap by generating a CycloneDX SBOM for each release of each custom application and loading it into OWASP Dependency-Track, which keeps component records tied to the application. Evidence: the SBOM files, the Dependency-Track project list and the record of which versions run in production.
Vulnerability scans treated as source monitoring
A recurring network or host scan finds vulnerabilities in running systems, but it does not tell you when a vendor or advisory source publishes a new flaw in a component you use. The SAQ D note to 6.3.1 is explicit that source monitoring is not achieved by the scans in 11.3.1 and 11.3.2. Close the gap by naming the industry sources you watch, such as vendor advisories and component feeds, and assigning an owner who logs each relevant item. Evidence: a dated source register and a log of advisories reviewed and actioned.
Risk rankings with no documented method
Teams often assign High or Critical labels to new vulnerabilities by instinct, with no written basis and no date. Requirement 6.3.1 requires risk rankings, and PCI SSC FAQ 1597 confirms that the entity may evaluate external rankings and assign its own based on its environment. Close the gap by writing a short ranking method that combines severity, exposure of the affected system and whether the component is in the payment flow, then recording the ranking date and approver for each item. Evidence: the ranking method document and the ticket history showing rank, date and reviewer.
Critical patches delivered late without justification
Under v4.0.1, Requirement 6.3.3 applies the one-month installation timeframe to patches for critical vulnerabilities. When a critical patch misses that window, assessors look for a recorded reason, a risk decision and an approved compensating action rather than a silent delay. Close the gap by adding a required exception record to the patch workflow that captures the reason, the interim control, the approver and a new target date. Evidence: exception tickets with approvals and the deployment dates of the patches that followed.
Non-critical patch timeframes set informally
Under v4.0.1, non-critical patches must be installed within a timeframe the entity determines. Many organizations leave that timeframe in chat messages or undocumented habit, so an assessor cannot confirm what the rule is. Close the gap by writing the timeframe for each patch category into your patch management standard, approving it through the owner of the system and reviewing it at least annually. Evidence: the approved standard, its version history and reports showing patches installed within those timeframes.
Inventory never refreshed after releases
An inventory built once for an assessment falls out of date after the next sprint, dependency upgrade or new container image. Requirement 6.3.2 now applies in full, so a stale list no longer shows the entity knows what it runs. Close the gap by making SBOM generation a step in the CI pipeline, using a scanner such as Trivy to produce an SBOM for each build, and comparing it with the previous release. Evidence: pipeline logs, dated SBOM artifacts for each release and a record of the components added or removed.
Questions buyers ask about PCI DSS 6.3 cost, effort and outside help
How much effort does PCI DSS 6.3 take to run?
The effort depends on how many components you run, how often they change, and how mature your tooling is, and no fixed duration is set by the standard. Requirement 6.3 covers three recurring jobs: watching industry sources and ranking new vulnerabilities, keeping an inventory of bespoke software and third-party components, and installing security patches. A team with a few applications on a stable release cycle can run these jobs with a small weekly routine. A team with hundreds of components, frequent releases and no central inventory will spend much more time on matching findings to assets and chasing owners. Before you request a quote, ask for an effort estimate based on your actual component count and release cadence, and confirm it against your own environment.
Can a small team handle PCI DSS 6.3 without outside help?
Yes, a small team can usually handle 6.3 alone if the inventory and the risk-ranking method are written down and the process repeats on a schedule. The work is mostly routine: a named person reviews vulnerability sources, records how each new finding is ranked for your environment, updates the component list when software changes, and tracks patches against their timeframes. Outside help is most useful at the start, when someone needs to build the inventory, connect the scanners and ticketing, and write the procedure. Once that is in place, your own staff can keep it running. Confirm that your team has the time and skills to maintain the process every month, not just to set it up once.
What does PCI DSS 6.3 require from our organization?
Requirement 6.3 requires named owners, access to the places where software is built and deployed, and records that show what happened. Assign an owner for vulnerability intake, another for the software inventory, and another for patch deployment, and make sure each owner has a backup. Your team also needs read access to build pipelines, package repositories and container registries so the inventory reflects what actually runs. Change records and ticket histories are the evidence an assessor will sample, so the patching process must link each finding to a decision and a deployment. Confirm these access paths early, because delays in getting them often hold up the whole project.
Does the 30-day patch deadline apply to every patch under PCI DSS 4.0.1?
No, under PCI DSS v4.0.1 the one-month (30-day) installation timeframe applies to patches for critical vulnerabilities only. Other security patches must be installed within a timeframe that you define and can justify through your risk analysis. This change matters for planning, because it means you need a defined ranking method that separates critical vulnerabilities from the rest and records the target date for each class. Document those timeframes in your policy, apply them consistently, and keep evidence that the work happened within them. Confirm the exact wording of your own policy with your assessor before the assessment.
Can an outside partner make our vulnerability risk ranking decisions?
No, the organization owns the ranking decisions, and a partner can only prepare the process and the evidence. PCI SSC FAQ 1597 makes clear that you do not have to accept risk rankings from external sources. You may evaluate them and assign rankings that fit your own environment, data and exposure. An implementation partner can set up feeds, record how rankings are assigned, and build the ticketing workflow, but the decisions and their rationale must come from your staff. Only the independent assessor reviews and reports on whether the process meets the standard.
What should we ask for in a written quote for 6.3 work?
Ask for a written scope, a list of deliverables, acceptance criteria, and a statement of who signs the evidence. The scope should name the systems, applications and component sources included, plus the tools and integrations that will be set up. Deliverables should include the inventory, the ranking procedure, the patch timeframes, and the runbooks your team will use after handover. Acceptance criteria should state how you will know the work is complete, for example by showing a sample of findings traced from intake to deployment. Finally, confirm who signs off the evidence on your side and who holds the records after the engagement ends. Fixed-scope agreements of this kind are how DeployOpen typically prepares this work, and the quote follows from that written scope.
How DeployOpen prepares 6.3 evidence for self-hosted platforms
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure so that vulnerability identification, software inventory and patch tracking under 6.3 produce evidence an assessor can read. We prepare systems and records; your organization owns the controls and the independent assessor issues the validation.
How we scope
- Agreed in writing before work starts, covering which platforms, repositories and components are in the 6.3 scope.
- Defines which industry vulnerability sources are monitored and how your team assigns risk rankings to new findings.
- Records who owns the software inventory, the patch decisions and the review of critical patch timeframes.
How we build
- Configures a vulnerability management service with scheduled tasks, user roles and stored results in your environment.
- Deploys SBOM generation and component tracking so custom software and third-party components appear in one inventory.
- Sets up finding deduplication and import pipelines so vulnerability records are traceable from source to ticket.
How we hand over
- Documents the configuration, data flows and tool owners so your assessor can trace how each 6.3 sub-requirement is met.
- Delivers sample reports, inventory exports and patch records as evidence, with a note on what each artifact shows.
- Provides runbooks for monitoring sources, ranking vulnerabilities and handling critical patches within the required timeframe.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
- Retainers can keep inventories current as components change and review tool updates before they reach production.
- Confirm with your assessor which evidence they expect for 6.3 before handover, since they decide what is sufficient.
