What PCI DSS 12.3 targeted risk analysis asks for and why teams struggle with it
If an assessor or QSA has asked for your targeted risk analyses and all you have is a spreadsheet or nothing, the gap is probably not the document. Requirement 12.3 covers three linked duties. First, targeted risk analyses for requirements where the entity chooses how often an activity happens (12.3.1) and for each requirement met through the customized approach (12.3.2). Second, a yearly review of the cryptographic cipher suites and protocols in use (12.3.3). Third, a yearly review of the hardware and software technologies in use, including vendor end-of-life announcements, backed by a remediation plan approved by senior management (12.3.4). The PCI SSC glossary defines a targeted risk analysis as a risk analysis that focuses on a specific PCI DSS requirement or requirements of interest. Requirement 12.3.1 became mandatory on 31 March 2025, so assessors now expect to see it in place.
The hard part is the reasoning, not the template. For 12.3.1, the analysis has to identify the assets, threats and likelihood or impact factors that bear on the requirement, then justify why the chosen frequency is sound for your environment. A log review performed monthly rather than daily, or a penetration test on a different cycle, is only defensible if the analysis shows why that interval manages the risk. An analysis that names a frequency without the reasoning behind it will not satisfy an assessor. Start by listing every requirement where you have set your own frequency, then ask a named owner to write down the threats and the evidence supporting each choice. Confirm the review date for each analysis, since the standard requires review at least every 12 months.
For 12.3.3 and 12.3.4, the work is recurring rather than one-time. Build a dated inventory of cipher suites, protocols, hardware and software, then record what industry monitoring or vendor announcements you checked and what you did about anything approaching end of life. Ask whether your tooling can produce those inventories automatically. Asset and inventory platforms such as GLPI or Wazuh's Syscollector can supply the raw data, but they do not write the analysis or approve the remediation plan. Confirm with your QSA how they want the analyses documented, which versions of the official templates apply, and whether your customized-approach analyses need the same depth as your frequency analyses.
Which requirements and systems bring 12.3 into scope
Requirement 12.3 applies only where your cardholder data environment and connected in-scope systems rely on a decision or technology that needs a targeted analysis. Each card below marks one trigger, and the number of analyses you need grows or shrinks with the requirements and systems you choose to cover.
Requirements with flexible frequencies
Some requirements let you set how often an activity runs, and each one you use needs its own targeted risk analysis under 12.3.1. The analysis must identify the assets, threats and likelihood or impact factors behind the chosen frequency and justify it. Check every requirement in your scope for a frequency you have set yourself, because each one adds an analysis to your annual review. Confirm the review cadence with your QSA before you set it.
Requirements met through the customized approach
Where you meet a requirement with the customized approach, 12.3.2 requires a targeted risk analysis for that requirement. Each customized implementation needs its own analysis that shows how your control meets the stated objective. Scope decisions matter here: fewer customized requirements in the cardholder data environment means fewer analyses. Note that the customized approach is open only to entities with robust security and risk management, so confirm your eligibility with your assessor before you commit.
Cryptographic cipher suites and protocols
Requirement 12.3.3 requires a documented inventory of the cipher suites and protocols in use across the cardholder data environment. The review must cover industry trend monitoring and a response strategy for weakening algorithms. Build the inventory from every system that terminates or initiates encrypted sessions, including load balancers, APIs and internal service links. Ask each team to name the protocol versions they actually negotiate, not just the versions they configured.
Hardware and software technology inventory
Requirement 12.3.4 requires that hardware and software technologies in use are reviewed at least every 12 months. The review must include vendor end-of-life announcements and a remediation plan approved by senior management. Your inventory should cover every in-scope component, including firmware, operating systems, appliances and libraries. Assign an owner to each item so that the review can show who acts on a retirement notice.
Systems and teams that own the technologies
The review in 12.3.3 and 12.3.4 only works if the teams that run in-scope systems feed their technology data into it. Network, platform, application and payment operations teams each hold part of the picture. Identify which team owns each asset class, and document how changes reach the review. Systems that the cardholder data environment depends on but that sit outside your direct administration still belong in the review.
Third-party platforms and end-of-life notices
Vendor platforms in your payment flow can change support status without warning, and their end-of-life notices feed the 12.3.4 review. List each third-party platform, the version you run and the vendor channel that announces support changes. Record the date each notice arrives and the decision it triggers. Ask providers how far in advance they publish end-of-life dates and whether they notify customers directly.
How a PCI DSS targeted risk analysis is built
A 12.3.1 targeted risk analysis has to show its working. For each requirement where the entity chooses how often an activity runs, the analysis names the assets that requirement protects, such as the cardholder data environment systems, log sources or payment applications the activity covers. It then lists the threats to those assets and the likelihood or impact factors that make a given frequency reasonable. The final element is the justification itself: a written statement that connects those factors to the interval chosen, for example why a particular log review or vulnerability scan runs monthly rather than quarterly. An assessor will read the frequency decision first and then look for the analysis that supports it, so a bare interval with no reasoning fails the check. Before you start, confirm the exact frequency wording in the requirement you are analyzing, since each targeted analysis is tied to one requirement.
The 12.3.2 targeted risk analysis covers a different situation. It applies when an entity meets a requirement through the customized approach, which lets it reach the stated objective with its own controls instead of the defined method. The PCI SSC's targeted risk analysis guidance treats this as a separate analysis from the frequency case because the question changes from how often to whether the entity's own control achieves the objective and how it is kept effective. The analysis documents the customized control, the risk it addresses, the threats it must withstand, and the evidence that the control still works as designed. Organizations often treat the two as interchangeable, but a frequency analysis that is missing the control description will not satisfy a customized approach assessment. Read the PCI SSC guidance directly before you choose which template to use: PCI SSC targeted risk analysis guidance.
Every targeted risk analysis must be reviewed at least every 12 months, and the review date should be recorded alongside the analysis so an assessor can see it was not left to lapse. An earlier update is needed when the environment or the threat picture changes in a way that could alter the justification. Typical triggers include a new payment channel, a change to the cardholder data environment or its network, a new system or service provider, a published vulnerability or attack pattern affecting a technology in use, or a finding in an assessment or internal review. The owner should be named in the document and should approve each revision. Ask your QSA early which of these triggers they expect to see documented, because the answer shapes how you record the change history.
How an assessor tests PCI DSS 12.3 and what they ask to see
This table sets out, for each of the four 12.3 sub-requirements, how an assessor examines the documented analysis, interviews the people who set frequencies, checks the reasoning against the environment and confirms the 12-month review date. Read each row as a checklist of what to have ready before the assessment starts.
| Sub-requirement | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| 12.3.1 Targeted risk analysis for flexible frequencies | Assessor examines each targeted risk analysis, then interviews the staff who chose the frequency and checks the stated reasoning against the actual environment and recent changes. | Dated analysis per requirement showing assets, threats, likelihood or impact factors, the chosen frequency, its justification and the last review date. | Frequency chosen with no stated reasoning, analysis that names no assets or threats, or a review more than 12 months old. |
| 12.3.2 Targeted risk analysis for the customized approach | Assessor compares the analysis with the customized implementation, confirming the stated objective is met and the risk analysis supports the design choice. | Per-requirement analysis tied to the customized control design, plus the objective it meets and the monitoring that shows it still works. | Analysis written after the control was deployed, a generic template reused across requirements, or no link between the risk and the design. |
| 12.3.3 Yearly review of cipher suites and protocols | Assessor requests the inventory of cryptographic suites and protocols in use, checks the review record, and asks how industry trend monitoring feeds the response strategy. | Current inventory of cipher suites and protocols, the review record with its date, notes on trend monitoring and a documented response strategy. | Inventory that omits some services or certificates, review not repeated within 12 months, or deprecated protocols still enabled with no response plan. |
| 12.3.4 Yearly review of hardware and software technologies | Assessor reviews the technology list against vendor end-of-life announcements, interviews the owner of the review, and checks that senior management approved the remediation plan. | Technology inventory, the annual review record, vendor end-of-life notices reviewed, and a remediation plan with senior management approval. | End-of-life components still in production without a dated plan, approval missing or undated, or the review covering only part of the estate. |
How to run the first PCI DSS 12.3 targeted risk analysis
This sequence turns the requirements that allow flexible frequencies or the customized approach into a documented, owner-backed targeted risk analysis that justifies how often each activity runs and is reviewed every 12 months. The organization performs the work internally first, and an outside partner can support the review stage if wanted.
List the requirements that need a targeted risk analysis
Start by listing every PCI DSS requirement where your entity sets its own activity frequency or meets the requirement through the customized approach. Your assessor's scope and your current SAQ or ROC will show which requirements apply to you. Your compliance lead or security manager does this work and records the list in a single register. The step is complete when each entry names a requirement, its approach (flexible frequency or customized), and the current frequency or control in use.
Assign a named owner to each entry
Assign one accountable owner to every register entry, usually the person who runs the control day to day, such as a network, log management or vulnerability management lead. The owner supplies the operational detail and is accountable for keeping the analysis current. Record the owner's name and role against each requirement. The step is complete when no entry is unowned and the owner has confirmed they will provide the inputs for the next steps.
Define assets and threats for each requirement
For each entry, the owner identifies the assets the activity protects, such as systems, data stores, or processes, and the threats that could affect them. Keep this tied to the cardholder data environment and the specific requirement, since the PCI SSC defines a targeted risk analysis as one focused on a specific requirement or requirements of interest. The output is a short asset and threat description per entry, reviewed by the compliance lead for completeness.
Record likelihood and impact factors
Document the likelihood and impact factors that bear on how often the activity must run, such as change rate, exposure to the internet, historical incident or finding data, and the consequence of a missed activity. Use a consistent scale across entries so reviewers can compare them. Keep the evidence behind each factor, such as change tickets or scan results. The step is complete when every entry has its factors recorded with a supporting source.
Set and justify the frequency for each activity
Using the recorded factors, set the frequency for each flexible activity and write a justification that links the frequency to the risk. The justification should explain why this interval is adequate for the identified likelihood and impact. The compliance lead challenges weak reasoning before sign-off. The output is a frequency decision per requirement, each with a written rationale that an assessor can follow without interviews.
Approve the analysis and schedule the 12-month review
Obtain documented approval from the executive or governance body responsible for the security program, and record the approval date, approver, and version of the analysis. Then schedule the review that PCI DSS requires at least every 12 months, and assign the owner of that review. Store the signed analysis with the policy and evidence set. The step is complete when the approved analysis and the review record exist in the evidence repository and the next review has a named owner and a calendar entry.
Evidence that passes a PCI DSS 12.3 review
A 12.3 review turns on whether each analysis is written down, justified and kept current, not on the existence of a single document. The six artifacts below connect because the targeted risk analyses set frequencies, the technology reviews feed them, and the remediation plan shows what happens when a review finds a gap. Keep each one dated, versioned and owned by a named person so the QSA can trace it from the 12-month cycle back to the source data.
Signed targeted risk analyses for flexible frequencies
Each requirement where you set your own activity frequency needs its own targeted risk analysis under 12.3.1. It should identify the assets and threats involved, the likelihood or impact factors, and the reasoning that justifies the chosen interval. Check that each analysis names its approver, carries a date, and shows a review no more than 12 months after the previous one. An analysis that cites a frequency the team no longer follows will fail review. Keep the analyses in your GRC or document repository with a change log for each revision.
Customized approach analyses
If you meet any requirement through the customized approach, 12.3.2 expects a targeted risk analysis for that requirement that explains how the stated objective is met. Each analysis should describe the control design, the assets it protects, and the risks it addresses, and it should be linked to the matching customized approach documentation. Ask whether the analysis was written before the control went live and whether it was updated after the environment changed. Keep it with the control's evidence so the assessor can test both together.
Cipher suite and protocol inventory
Requirement 12.3.3 expects a documented inventory of the cryptographic cipher suites and protocols in use, reviewed at least every 12 months. Good evidence shows the inventory itself, a record of how you monitor industry trends for weakened algorithms, and a response strategy that says how you will retire or replace each weak item. Confirm that the inventory covers systems outside the CDE that feed into it, and that the review date and reviewer appear on each version. A scan export attached to a dated review record is stronger than an unsigned spreadsheet.
Hardware and software technology list
Requirement 12.3.4 expects a review of the hardware and software technologies in use at least every 12 months. The list should include each technology, its version, its owner, and the vendor end-of-life or end-of-support announcements that apply to it. Keep the vendor notices with the list, dated when you received them, so the assessor can see when you learned about each change. An asset inventory from your management tooling can supply the raw data, but the review record must show a person looked at it.
Senior-management-approved remediation plan
When a 12.3 review finds an end-of-life technology or a weak cipher, 12.3.4 expects a remediation plan that senior management has approved. The plan should list each affected item, the planned replacement or compensating step, the accountable owner, and the target date. Check that approval is recorded with a name, a role and a date, and that progress is noted at each later review. Assessors commonly ask for the approval record itself, so a plan without it will not count.
Record of each 12-month review
Assessors look for proof that every 12.3 activity ran on schedule, and a single review log is the simplest way to show it. The log should list each analysis, inventory and technology review with its date, reviewer, outcome and the version of the artifact that was reviewed. Link each entry to the files it covers and record any changes made as a result. Set calendar reminders tied to the earliest review date across all artifacts so that no item lapses between assessments.
What it costs to meet PCI DSS 12.3
This table compares the main cost components of the 12.3 work, who is paid for each one, whether it is one-time or recurring, and what drives it up or down. Read it as a scoping checklist: most of the spend depends on how many requirements use targeted risk analyses and how large the technology estate is, not on any single tool license.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Internal targeted risk analysis effort | One-time build, then recurring | Number of requirements where the entity sets its own activity frequency, and the depth of asset, threat and likelihood analysis for each | Reuse one analysis template across requirements and document frequency justifications in one register |
| Cryptographic suite and protocol inventory (12.3.3) | One-time inventory, recurring review | Number of systems, services and certificates that negotiate TLS or other cryptography, and how many are managed outside central tooling | Pull protocol and cipher data from existing scanners and configuration baselines rather than manual surveys |
| Hardware and software technology review (12.3.4) | One-time baseline, recurring review | Size of the asset inventory, accuracy of software records, and how many vendors publish end-of-life dates that must be tracked | Keep one authoritative asset inventory with automated discovery so the yearly review starts from current data |
| Remediation planning and senior approval | Recurring, tied to review findings | Number of end-of-life or weak-cipher findings, and the scope of replacement work they trigger | Schedule known end-of-life replacements early and record approval in a standing governance forum |
| Tooling and licenses | Recurring where commercial, one-time for setup | Commercial GRC or inventory licenses, and the hosting and storage for scan and inventory data | Self-hosted open-source platforms remove license spend, but staff time for deployment, tuning and upkeep remains |
| Staff time for ongoing upkeep | Recurring every 12 months | Change rate in the environment, staff turnover, and how often analyses are reopened after changes | Trigger analysis updates from change management so reviews are incremental, not full rebuilds |
| External facilitation | Optional, usually one-time with follow-up reviews | Team familiarity with targeted risk analysis, and the number of analyses that need method and documentation support | Ask for a fixed-scope facilitation with named deliverables, and keep ownership of the analyses in-house |
| QSA time examining the analyses | Recurring with each assessment | Quality and traceability of the analyses, and how many need explanation during the assessment | Provide complete analyses, versioned records and evidence of the 12-month review before fieldwork starts |
Who owns the analysis: your team, a partner and the QSA
Your organization owns every targeted risk analysis that Requirement 12.3 calls for. That means deciding which requirements have a flexible frequency, choosing the assets, threats and likelihood or impact factors that justify each frequency, and approving the outcome in writing. The same ownership applies to the annual reviews of cryptographic cipher suites and protocols under 12.3.3 and of hardware and software technologies under 12.3.4, including the senior-management-approved remediation plan that 12.3.4 expects.
- Decision rights: Name the person who approves each analysis and the date it was approved, so the approval is traceable.
- Business context: Only your staff know which systems carry the most risk, which vendors are changing and which teams run the change process.
- Frequency justification: Write down why a given frequency is appropriate for your environment, not only that a frequency was chosen.
- Ongoing reviews: Schedule the 12-month reviews and assign an owner for each, because they recur for as long as the standard applies.
- Remediation follow-through: Track the actions that come out of the technology review to completion.
Before accepting any outside draft, check that your own team can explain each analysis to an assessor without reading the document aloud.
An implementation partner can prepare the material your team uses to make these decisions. Typical work includes building the hardware and software inventory, collecting cipher suite and protocol data from the systems in scope, drafting analysis templates, running facilitation workshops and organizing the evidence into a folder your team reviews. Partners can also help with the technical reading of vendor end-of-life announcements. The partner works for you, under a written scope, and its drafts become your analysis only after your team reviews and adopts them.
- Inventory preparation: Collect asset data from endpoints, servers and network devices, using tooling where your environment supports it.
- Draft analyses: Prepare first drafts that your owners challenge, correct and sign.
- Facilitation: Run workshops that bring together security, operations and application owners.
- Evidence organization: Arrange approvals, inventories and review records so an assessor can find them.
- Independence limit: A partner cannot act as the QSA for the same engagement, and it cannot sign off the compliance result.
When you scope a partner, ask which deliverables are drafts, who signs each one and how the partner's conflicts of interest are handled.
A Qualified Security Assessor, or another assessor your payment brands accept, tests whether the 12.3 analyses exist, meet the requirement and operate as described. The assessor reviews the documentation, interviews the owners and examines the inventories and approvals, then reports the result in the Report on Compliance. The assessor does not write your analysis as its own work. If it helped build the analysis, it generally cannot also test it, so the separation between preparation and assessment matters from the start.
- Testing role: Review whether each analysis identifies assets, threats and likelihood or impact, and justifies the frequency.
- Sampling: Expect the assessor to select specific requirements and systems to trace from the analysis through to the evidence.
- Report role: The QSA issues the ROC and the assessment conclusion. Only the assessor's signed documents count as validation.
- Advisory limits: Ask in advance what advice the assessor may give during the engagement and what it will not do.
- Engagement terms: Confirm the assessor's independence policy and the payment brand requirements that apply to your entity.
Before the assessment begins, confirm with the assessor which analysis format it expects and how it will test the technology review under 12.3.4.
Open-source tools that produce 12.3 evidence
Requirement 12.3 is judged on documents and review records, so the analysis register, the asset inventory and the endpoint software data each need a home. The three tools below can hold or produce that evidence, but none of them performs the risk analysis or makes the frequency decision, which stays with the organization and its assessor.
Analysis register and audit workflow
CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including PCI DSS, and can run audits and compliance assessments against them with automatic mapping between frameworks. For 12.3.1, it can hold each targeted risk analysis as a dated record with the assets, threats, likelihood or impact factors and the justification for the chosen frequency, plus the 12-month review date. Check that the framework version you assess against matches PCI DSS v4.0.1, and confirm that the mappings it applies are ones your assessor accepts before relying on them.
Hardware and software inventory
GLPI (GPL-3.0-or-later) Assets manages computers, monitors, software, network equipment, peripherals, printers, phones and racks. Its native inventory, built into GLPI since version 10, can be fed by the GLPI Agent, so records can be pushed automatically instead of typed in. This inventory is the starting point for the 12.3.4 review of hardware and software technologies, where you match each item against vendor end-of-life announcements and a remediation plan approved by senior management. Confirm that the agent reports the fields your review needs, since entries that are stale or incomplete will weaken the evidence.
Endpoint software and open ports
Wazuh (GPL-2.0-only) Syscollector collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint, and stores the results in the Wazuh indexer for dashboard inventory views and reports. For 12.3.4, this gives an observed list of what actually runs, which you can compare with the GLPI record and with the review you signed off. Confirm which endpoints report to Wazuh, because an endpoint that is missing from the view leaves a gap in the review.
Cipher and protocol coverage gap
None of the supplied tool facts covers cryptographic cipher suites or protocols, so the 12.3.3 review cannot be assumed to be met by any tool listed here. The inventory from Wazuh and GLPI may show that a service is listening, but not which cipher suites or protocol versions it negotiates. Build the cipher and protocol inventory from your own configuration review and TLS scanning, record the monitoring of industry trends and the response strategy, and confirm coverage in your environment before the assessor arrives.
Common questions about PCI DSS 12.3 costs, effort and outside help
Can a small team complete PCI DSS 12.3 on its own?
Yes, a small team can write the targeted risk analyses itself, provided it knows which requirements it is analyzing and who owns each system behind them. The work is documentation and judgment rather than tooling, so the limiting factors are time and access to the people who know the environment. A team that already runs its own PCI DSS program usually needs an outside reviewer only to check the reasoning, not to produce the documents. Teams with few people often find the hardest part is keeping the analyses current once the first set is written, because each one must be reviewed at least every 12 months under Requirement 12.3.1. Confirm internally who will own that calendar before deciding whether to hire help.
How long does PCI DSS 12.3 take to complete?
The effort depends mainly on how many requirements in your assessment use flexible frequencies or the customized approach, because each one needs its own targeted risk analysis. A environment with a few such requirements is a much smaller exercise than one where many activities have been moved to entity-set schedules. Other drivers include how many systems and business units sit in scope, how much existing evidence is already documented, and how quickly owners can answer questions. No standard duration applies, so ask any partner to state the assumptions behind its estimate, including the number of requirements, the number of interviews and the review workshops it expects.
What does the work need from business and technical owners?
The analyses need named owners who can describe assets, threats and the factors that affect likelihood or impact for each requirement. Technical owners supply the facts: which systems perform the activity, how often logs are reviewed in practice, and what the current configuration looks like. Business owners decide whether the chosen frequency is acceptable against the organization's risk appetite and sign off on the justification. Requirement 12.3.1 expects the frequency to be justified, so vague answers such as 'we do it when needed' will not hold up. Plan for short working sessions with each owner, and record who approved each analysis and when.
Can a QSA write the targeted risk analysis for us?
No. The entity owns its risk analyses, and the Qualified Security Assessor evaluates them during the assessment rather than writing them. An assessor that drafts the analysis would be reviewing its own work, which compromises the independence the assessment depends on. A consultant or implementation partner can help you prepare the inputs, structure the documents and walk your team through the method, but the content must reflect your own assets, threats and decisions. Ask any firm to show how it keeps preparation separate from assessment, and make sure your staff can explain each analysis without the consultant in the room.
What does the 12-month review cycle demand each year?
Each year, the organization must re-review every targeted risk analysis, confirm the assets and threats are still accurate, and check that the chosen frequencies remain justified. Requirements 12.3.3 and 12.3.4 add yearly reviews of cryptographic cipher suites and protocols, and of hardware and software technologies, including vendor end-of-life announcements and a remediation plan approved by senior management. The recurring cost is mostly internal staff time, plus any consultant support you choose to buy for refreshes. Drivers include the number of systems, how often they change, and how many vendors announce end-of-life dates. Build the review into the same calendar as your scope confirmation and policy review to avoid three separate exercises.
What should we ask a partner for in a fixed-scope quote?
Ask for a written scope that lists each requirement covered, the number and type of targeted risk analyses to be prepared, the systems and business units included, and the owners and sessions your team must provide. The quote should state the deliverables, such as the analyses, a review calendar and the evidence files, and what is excluded, such as the assessor's fees or the remediation of any gaps found. Confirm how changes to scope are handled, who keeps the working documents, and whether the partner will support the first 12-month review. DeployOpen works from a written, fixed scope agreed before work starts, and does not publish a price list, so a quote follows from that scope. Ask any provider for the same clarity, and confirm that the assessment itself will be performed by an independent QSA.
How DeployOpen prepares targeted risk analyses and 12.3 evidence
DeployOpen helps organizations prepare the targeted risk analyses and review records that Requirement 12.3 expects, inside their own infrastructure. The organization owns its risk decisions and frequencies, DeployOpen prepares the systems, inventories and evidence, and an independent QSA or assessor judges whether the result meets the standard.
How we scope
- Agree in writing which requirements need a targeted risk analysis under 12.3.1 or 12.3.2, and which 12.3.3 and 12.3.4 reviews apply.
- Confirm the asset, technology and cryptography inventories that each analysis will draw on before work starts.
- Engagements are fixed-scope, so deliverables, responsibilities and timelines are agreed in writing before any work begins.
How we build
- Set up a documented template for each targeted risk analysis covering assets, threats, likelihood or impact factors and the justification for the chosen frequency.
- Configure inventory tooling such as GLPI assets and Wazuh system inventory so hardware and software records feed the 12.3.4 review.
- Build a recurring review calendar for the 12-month cycle, with cipher suite and protocol checks recorded against the 12.3.3 documented inventory.
How we hand over
- Deliver the completed risk analyses, review records and remediation plans, with named owners for each decision in the organization.
- Provide a walkthrough so your security and compliance staff can explain each frequency decision and its evidence to an assessor.
- Document the operating procedure for repeating each analysis every 12 months, so the program continues after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for teams that refresh analyses between assessments.
- Ask us to update analyses after significant changes to technology, cryptography or vendor end-of-life announcements.
- Assessment decisions, reports and attestations stay with your independent QSA or assessor, and DeployOpen does not issue them.
