CA-8 penetration testing requirements: what the control asks for
If your organization runs a high-impact system, CA-8 expects a penetration testing program that goes beyond vulnerability scanning. The control requires that systems or system components you define be penetration tested at a frequency you define. NIST's catalog treats penetration testing as a specialized assessment aimed at finding weaknesses that an attacker could actually exploit, not just listing known flaws. In SP 800-53B, the control is selected in the high baseline and not in the low, moderate or privacy baselines, so a moderate system does not inherit the requirement unless your authorizing official or contract adds it. The enhancement CA-8(1), which calls for an independent penetration testing agent or team, is also selected only in the high baseline. Confirm the baseline selection against your system's categorization and any tailoring decisions documented in your security plan before you scope the work.
Three difficulties come up repeatedly. The first is scope: the control leaves the systems and components to be tested for you to define, so the boundary has to match the system security plan, including external interfaces, cloud accounts and any shared services. The second is frequency, which is also yours to set and must be justified and followed. The third is the line between penetration testing and vulnerability scanning. Scanners such as Greenbone Community Edition (OpenVAS) produce useful inventories of known weaknesses, but a penetration test chains weaknesses, tests access paths and reports what a tester could reach. Keep the two results separate in your records. Finally, every confirmed weakness should flow into the plan of action and milestones under CA-5, with an owner and a planned completion date, so that the penetration test does not end as a PDF that nobody tracks. Ask your assessor how they expect scan results and penetration test findings to be reconciled before the first test begins.
Which systems and teams CA-8 applies to in practice
CA-8 is selected only in the high baseline, so the first decision is whether a system is categorized high impact. Once it is, the organization must define which components the penetration test covers and who runs the program, because those choices determine the work more than the test method does.
Confirm high-impact categorization first
SP 800-53B selects CA-8 in the high baseline and not in the low, moderate or privacy baselines, so the security categorization of the system decides whether this control applies at all. Re-check the categorization after major changes to the data a system holds or the missions it supports. Record the categorization decision in the system security plan so an assessor can trace why penetration testing is or is not in the control set.
Define in-scope components explicitly
CA-8 requires the organization to define the systems or components to be tested, so the scope must be written down rather than inferred by the testers. Typical in-scope items include external interfaces, internal network segments, cloud accounts, APIs and mobile applications. For each item, record the owner, the environment and whether production testing is allowed. Ambiguous scope is the most common reason a test later fails to answer the assessor's questions.
Coordinate cloud and provider-hosted components
Cloud accounts, managed databases and SaaS components often sit outside the organization's direct control, and each provider has its own testing rules. Confirm which provider permissions, notification steps and exclusions apply before testing starts. Components that a common control provider or a third party operates may be covered by that party's test, so the organization must document who tests what and obtain the resulting report for its evidence file.
Include inherited and supplier components
When a system inherits controls from a shared service or depends on a supplier's software, penetration testing of those components may need a written agreement with the supplier. Check the contract for testing rights, reporting obligations and remediation timing before assuming coverage. Related controls in the SA and SR families address how these supplier obligations are written, so review them together with CA-8 when the system relies heavily on third parties.
Assign the test program owner
The system owner typically funds and schedules the penetration test, while a security assessment team or independent tester performs it. Where a common control provider runs the shared environment, that provider may own the test and share results with each inheriting system. Name each role in the assessment plan and confirm who accepts findings and approves remediation, since CA-8 evidence is judged by whether that accountability is visible.
Plan independence for the high baseline
CA-8(1) asks for independent penetration testing agents or teams, which is the enhancement selected in the high baseline. Decide early whether internal staff, an external firm or a mix will test, and confirm that the tester is separate from the people who built or operate the system. Ask any firm to show how it separates testing from configuration duties before engagement, because the separation is what the assessor will check.
How to implement a CA-8 penetration testing program step by step
This sequence takes an organization from naming the systems in scope to proving that exploitable weaknesses were found, fixed and retested, with a dated record for each step that an assessor can review.
Define systems in scope and the testing frequency
The organization, through its system owner and security lead, names the systems or components that CA-8 covers and sets the penetration testing frequency it commits to, since CA-8 leaves both as organization-defined values. Only the high baseline selects CA-8 in SP 800-53B, so confirm with the authorizing official whether your system is categorized high before scoping the work. Output: a scope statement listing included systems, excluded components with reasons, and an approved frequency signed by the accountable owner. An assessor will ask to see this first, because every later test is measured against it.
Write the test plan and rules of engagement
The security team drafts the test plan, covering objectives, methods, testing windows, permitted techniques, out-of-scope actions such as denial of service on production, emergency contacts and data handling for any sensitive information the tester encounters. The rules of engagement are the signed agreement that authorizes the tester to act and protects both parties. Output: an approved test plan and signed rules of engagement, both retained as assessment evidence. Confirm that the plan is reviewed by the people who will be contacted if testing causes an incident.
Choose the tester model
Decide whether the work is done by an internal team, an external firm, or a mix. CA-8(1) requires an independent penetration testing agent or team when the high baseline applies, so the tester must be independent of the people who built or operate the system. Document the selection rationale, the testers' qualifications and any conflict-of-interest checks. Output: a tester selection record that shows who was chosen, why, and how independence was confirmed. Ask any external firm for its written scope, method description and sample report before signing.
Execute the test and document the results
Testers carry out the approved methods within the agreed windows, and the test lead logs each action, each exploitable finding and each attempt that failed. The output is a penetration test report that states the systems tested, dates, methods, tools, findings with severity and reproduction steps, and any testing limits. Your team confirms that the activity stayed within the rules of engagement and records any deviations. An assessor will compare this report with the approved plan, so mismatches in scope or dates should be explained in writing before the report is filed.
Triage and track findings in a remediation record
Each finding is validated, assigned an owner and a remediation action, and entered into the plan of action and milestones (POA&M) where it is not closed immediately. Open-source tooling such as DefectDojo can import and deduplicate findings from many scanner formats, which helps keep penetration test results in the same register as vulnerability scans. Output: a remediation record linking each finding to its fix, risk acceptance or compensating control, with approval. Ask whether accepted risks have a named approver and a review date.
Retest and close the loop
Once fixes are deployed, the affected findings are retested to confirm that the exploitable path no longer works, and the results are recorded against the original finding. Retests that fail reopen the item. Output: retest evidence attached to each closed finding, and an updated POA&M showing status. Where a finding is closed by risk acceptance rather than a fix, the record should show who accepted it and on what basis. This closure evidence is what shows that the testing led to action rather than a filed report.
Review the program and feed results into assessment
Periodically, the program owner reviews whether the frequency still fits the system, whether scope changed, and whether findings are trending toward the same weaknesses. Results feed into control assessments and continuous monitoring, and changes to the system trigger a scope review. Output: a documented review with decisions on scope and frequency, passed to the authorizing official. Confirm with your assessor which artifacts they expect in the next assessment cycle, since the exact evidence set depends on how your authorization package is organized.
How an assessor tests CA-8 and what they ask to see
This table breaks down the SP 800-53A assessment approach for CA-8 by method and object, with the common findings that appear when each object is weak. Read it as a checklist of what to prepare before an assessor arrives, remembering that the assessor's conclusions come from their own testing rather than from your summary.
| Assessment element | What the assessor examines, interviews or tests | Common findings to prevent |
|---|---|---|
| Determination statement | One determination statement covers whether penetration testing is performed at the organization-defined frequency on defined systems or components. The assessor checks that both values are set and followed. | Frequency and target systems are never defined, or the defined frequency is not met across the assessment period. |
| Examine: assessment plan | The assessor reads the plan to confirm the penetration test scope, rules of engagement, tester independence and how results feed the assessment. | Plan exists but does not name the systems in scope or does not match the systems actually tested. |
| Examine: penetration test report | The assessor reviews the report for scope, methodology, exploitation attempts, findings, severity and retest results. | Report lists scanner output only and does not show exploitation attempts or validated attack paths. |
| Examine: assessment report and evidence | The assessor compares the assessment report and supporting evidence, such as test dates, tester identity and raw tool output, against the plan. | Evidence is missing dates or tester identity, so the test cannot be tied to a defined period. |
| Interview: personnel with control assessment responsibilities | The assessor asks who schedules tests, who receives results and how the organization decides what to fix. | Staff cannot explain the test cycle or who owns remediation decisions. |
| Interview: system and network administrators | The assessor asks administrators how test findings reached them and how they verified fixes on the affected components. | Administrators did not receive findings, or fixes were not verified by a retest. |
| Test: mechanisms supporting penetration testing | The assessor may check that the tools, accounts and logging used in testing function as described, including whether test activity is visible to monitoring. | Testing mechanisms are undocumented, or test traffic cannot be distinguished from real attacks in logs. |
| Tracking of findings | The assessor traces each significant finding to a remediation action, owner and due date, usually in the plan of action and milestones. | Findings with no POA&M entry, or entries that were closed without a retest. |
Penetration test evidence that passes an audit
An assessor testing CA-8 looks for a connected trail: a plan that defines what gets tested and how often, rules of engagement that authorized the work, a report that shows what was exploited, proof that fixes were retested, and tracked remediation. The organization owns this evidence and keeps it current, while the independent assessor decides whether it is sufficient.
Assessment plan with defined scope
The plan names the systems or components subject to penetration testing and the frequency the organization defined for them. It also states the testing approach and who is responsible for each part of the work. Check that the systems listed match the current system inventory and authorization boundary, because a plan that omits newly added components will draw an assessor finding. Date each version and record who approved it.
Signed rules of engagement
Rules of engagement record the authorized targets, testing windows, permitted techniques, excluded systems, emergency contacts and data handling limits. They should be signed by someone with authority over the systems under test, and the tester should countersign. Keep the signed copy with the test report so the assessor can confirm the work was authorized and stayed inside agreed boundaries.
Penetration test report
The report should state the scope, testing method, tester identity and the findings that were actually exploited, with severity, affected asset and reproduction steps. Separate confirmed exploitable weaknesses from scanner output that was never validated, since assessors read those differently. Tester identity matters when the enhancement requiring independent testers applies. Confirm that the report is dated and tied to the version of the system that was tested.
Retest evidence
Retesting shows that each exploited finding was fixed and that the fix works. Keep the original proof of exploitation, the change record that deployed the fix and the retest result side by side. A retest that only confirms a ticket was closed is weak evidence, so ask the tester to reproduce the original attack path and record the outcome.
Linked POA&M and closure records
Each exploited finding that is not fixed immediately should appear in the plan of action and milestones with an owner, a planned completion date and a status. Closure records show the date and the evidence that closed each item. The assessor will trace a finding from the report to the POA&M to the retest, so the identifiers should match across all three documents.
Keeping evidence current between tests
Store every artifact with a version number and date, and keep prior versions instead of overwriting them. Maintain a dated schedule for the next penetration test that reflects the frequency in your plan, and update it when the system boundary changes. Vulnerability scanning output from tools such as Greenbone or DefectDojo can show ongoing activity between tests, but it does not replace the penetration test report.
What a CA-8 penetration testing program costs to run
This table compares the cost components of a CA-8 penetration testing program, showing who is paid, whether each cost is one-time or recurring, what moves it up or down, and what to request in a quote. The supplied facts contain no pentest pricing, so treat every cost as a scope question to answer with written quotes from vendors and testers.
| Cost component | One-time or recurring | What drives it up or down | What to request in a quote |
|---|---|---|---|
| External tester fees | Recurring per test cycle | Number and type of in-scope systems, test depth, number of testing days, and whether the tester is independent of the organization's staff | Written scope listing systems, test types, rules of engagement, testing window, named tester qualifications and the deliverable format |
| Internal tester time | Recurring per test cycle | Staff hours to prepare scope, provide access, coordinate testing windows and review findings with the tester | An estimate of internal hours per phase, and whether the organization's own staff or a separate team will test |
| Tooling and licenses | Recurring, with some one-time setup | Commercial testing suites and their seat counts, versus open-source scanners and self-hosted hosting effort | Which tools the tester brings, which license terms apply to the organization's data, and whether tool output is delivered in a reusable format |
| Remediation effort | Recurring, driven by each finding | Number and severity of exploitable weaknesses, age of affected components, and how many teams own the fixes | Severity ranking of findings, suggested fix paths and whether retest is included in the fixed price |
| Retest effort | Recurring per remediation cycle | Number of findings marked fixed, complexity of verification, and whether retests are bundled or billed separately | Retest terms, time limits for retests and the cost of each additional retest round |
| Evidence upkeep | Recurring | Retention period for test reports, depth of linkage to the plan of action and milestones, and assessor requests during authorization | Confirmation that the final report, scope, rules of engagement and remediation records will be delivered in a form an assessor can review |
Which open-source tools support CA-8 evidence
Penetration testing under CA-8 produces findings that must be tracked, deduplicated and remediated. The open-source tools below help organizations gather vulnerability data, manage scan results and keep findings in one place, but none of them performs the penetration test itself. Confirm each license with counsel before deployment, especially where you modify or distribute the software.
Wazuh vulnerability detection
Wazuh correlates the software inventory that each agent collects with its CTI vulnerability repository to identify weaknesses in the operating system and installed applications of monitored endpoints. For CA-8, this gives you continuous evidence of exposed software between tests, which helps scope a penetration test and check whether known issues were fixed afterward. Confirm whether your environment can use a locally hosted offline copy of the repository if endpoints cannot reach the internet. Wazuh is licensed under GPL-2.0-only, so review distribution obligations if you modify the code.
Fleet vulnerable software detection
Fleet matches software installed on enrolled hosts against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Its value for CA-8 is host-level visibility into the software a penetration tester would target, so the test scope and the remediation record start from the same inventory. Confirm which advisory sources cover your operating systems, since coverage differs by platform. Fleet is released under the MIT license, which is permissive, but confirm the terms that apply to any hosted or bundled version you run.
DefectDojo findings management
DefectDojo imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition, and offers a generic findings import for other outputs. It deduplicates findings using per-tool hashcode fields, so a retest that confirms or closes a penetration test finding updates the existing record rather than creating a duplicate. Your assessor can then trace each finding from the penetration test report to its remediation. Confirm which report formats your testers and scanners produce. DefectDojo is licensed under BSD-3-Clause.
Greenbone Community Edition scanning
Greenbone Community Edition (OpenVAS) uses gvmd as a vulnerability management service that stores results in PostgreSQL, manages users and permissions, and schedules scan tasks. Users run scans and review results in the Greenbone Security Assistant web interface. For CA-8, it supplies recurring network scan evidence and access records that support the scope of a penetration test, but it does not exploit weaknesses. Confirm scan authorization, PostgreSQL backup and user access reviews before relying on its output. Greenbone Community Edition is licensed under AGPL-3.0-or-later, which has network-use obligations for modified versions that you must review.
Who runs the penetration test and who checks it
Your organization owns CA-8 from start to finish. Its leaders decide which systems and components fall inside the penetration testing program, set the organization-defined frequency and approve the rules of engagement that govern how far testers may go. These decisions carry operational and security risk, so they belong to people with authority over the system.
- Defined systems and frequency: Name the systems or components in scope and the testing frequency, then record the reasoning in the system security and privacy plan.
- Rules of engagement: Approve testing windows, permitted techniques, data handling, stop conditions and escalation contacts before any tester touches a system.
- Independence decision: If the system is in the high baseline, CA-8(1) calls for an independent penetration testing agent or team. Decide whether internal staff or an outside firm meets that test, and document the reasoning.
- Remediation ownership: Assign an owner to each exploitable finding, set target dates and keep the plan of action and milestones current.
Check that the scope statement, frequency and rules of engagement are signed by someone with authority over the system before the first test begins.
An implementation partner prepares the systems, documents and evidence that make penetration testing repeatable and traceable. Outsourced work typically includes drafting scope documents and test plans, building the tooling and findings workflow and performing fixed-scope testing when the contract includes it. Ask for each of these items in writing so that no role is left unassigned.
- Scope and plan documents: Draft the scope statement, test plan and rules of engagement for your approval, mapped to the systems named in your security plan.
- Tooling and findings workflow: Set up self-hosted tools such as Greenbone Community Edition for scanning, Wazuh for vulnerability detection on endpoints, or DefectDojo for importing, deduplicating and tracking findings. Confirm each tool's capabilities against its current documentation before you rely on it.
- Testing under fixed scope: Where the contract includes testing, the scope, deliverables and timeline are agreed in writing before work starts.
- Evidence packaging: Assemble the penetration test report, remediation tickets and retest records so the assessor can examine them without reconstructing events.
The partner that performs or manages a test should not also judge whether the test was adequate. If the same firm runs the test and writes the adequacy conclusion, the assessor has nothing independent to rely on.
Check that the contract names who signs the test report, who receives the findings and that the partner's role stops at preparing and performing work.
An independent assessor tests the evidence and issues the conclusions. This role belongs to an auditor, assessor or certification body that is separate from your staff and from the partner that prepared the test. An assessor who helped design or run the test is not independent for that test. The assessor examines the test plan, the penetration test report and the remediation record, interviews the people who carried out the work and reports whether CA-8 is met.
- Examine the plan and report: Review the assessment plan, the penetration test report and related assessment evidence against the CA-8 procedure in SP 800-53A.
- Interview responsible staff: Speak with the personnel responsible for control assessment and the system administrators who supported the test.
- Test the supporting mechanisms: Check that the tools and processes used for penetration testing work as the documentation describes.
- Issue the findings: Only the assessor issues assessment results. The authorizing official relies on those results when deciding whether to authorize operation.
Confirm the assessor's independence and that its engagement covers CA-8 evidence before any testing begins, so the findings can be relied on later.
When CA-8(1), CA-8(2) and CA-8(3) change the work
CA-8(1) changes who performs the testing. It calls for penetration testing by an independent agent or team, so the testers must sit outside the people who build, administer and defend the system under test. An internal group that reports to the same manager as the operations team may not meet that expectation, and the assessor decides how much separation is enough. Before testing starts, ask the assessor how independence is judged, whether internal staff can qualify, and what documents prove it, such as reporting lines, conflict statements and the engagement letter. The penetration test report should name the testers, state their independence basis and list the defined systems covered. SP 800-53B selects this enhancement in the high baseline only, so confirm with the assessor whether your system categorization requires it at all. The CPRT entry for CA-08 is the place to read the control wording itself.
CA-8(2) covers red team exercises, which widen the test from finding vulnerabilities in a defined scope to pursuing defined objectives the way an adversary might. The rules of engagement usually expand, and they may allow social engineering, chained attacks or stealthy techniques, but only what the organization approves in writing. Defenders may not be told in advance, so the scope document, the authorized objectives and the deconfliction contacts become core evidence. The final report should describe what the team reached, what it touched and what the security operations staff detected or missed. The supplied facts do not state how SP 800-53B selects CA-8(2) for any baseline, so confirm that point with the assessor and your authorizing official before scoping, and agree on the rules of engagement and emergency stop procedure in advance.
CA-8(3) extends testing to facilities, meaning physical penetration testing of the locations that house or connect the system, such as data centers, network closets and offices with console access. The scope now includes people and physical controls, and the test may attempt entry, tailgating or access to equipment. The evidence shows whether the physical access controls in the Physical and Environmental Protection family worked as documented. Coordinate with facility owners, landlords and any colocation provider, since they may need written consent and have their own testing rules. Many systems run in facilities the organization does not operate, so confirm with the assessor and the provider which locations are in scope and whether the provider's own physical testing reports will be accepted as evidence. Ask the assessor to record each enhancement and its parameters in the assessment plan before any test begins.
CA-8 penetration testing questions buyers ask
How much does CA-8 penetration testing cost?
No supplied fact gives a price or fee for CA-8 work, so the honest answer is that cost depends on scope, not on the control number itself. The main cost components are the tester's time, the environment the test runs in, the internal effort to prepare and remediate, and the authorizing official's review. Ask for a quote that separates one-time work (planning, the first test, rules of engagement, the initial report) from recurring work (repeat tests at your defined frequency, retesting after fixes, and updates to the assessment plan). Drivers that raise cost include the number of systems in the defined scope, the number of external and internal attack surfaces, and whether a separate independent tester is used under CA-8(1). Confirm the exact frequency and scope with the authorizing official before you ask for pricing.
How long does a CA-8 penetration test cycle take?
The duration of a cycle is set by the defined scope and the frequency your authorizing official approves, and no supplied fact gives a number of days or weeks. A cycle usually includes scoping and rules of engagement, testing, reporting, remediation and retesting, and each stage can wait on the one before it. Timing also depends on change windows for production systems, the availability of system administrators who must be interviewed, and whether findings feed into a plan of action and milestones. Ask any provider to show the stages and the dependencies on your side in a written schedule. Treat the frequency itself as an organization-defined parameter that you confirm, record in the system security and privacy plan, and tie to significant changes in the system.
What does the internal team need to provide for a penetration test?
Internal staff must provide access, context and decisions that a tester cannot provide alone. The SP 800-53A assessment procedure for CA-8 names an assessment plan, a penetration test report and assessment evidence as examine objects, and it names system and network administrators and personnel with control assessment responsibilities as interview objects, so those people need time in the schedule. Typical internal inputs include an accurate asset inventory for the defined scope, network diagrams, test accounts with agreed privileges, named contacts for emergencies, approved testing windows, and a decision owner for each finding. Ask the provider which of these inputs they need in writing before the test starts.
Can our own team run CA-8 penetration tests in-house?
Yes, SP 800-53 does not require an outside firm for the base CA-8 control, so an internal team can perform the tests if it has the skills, tools and independence the organization needs. The control asks for penetration testing of defined systems at a defined frequency, and the assessment depends on the quality of the assessment plan and report. The independence question matters most when you select CA-8(1), which calls for an independent tester in the high baseline. In that case the internal team cannot be the only tester for the in-scope systems. An in-house team can also use open-source tooling for the discovery and evidence work, but exploit development, attack chains and reporting still need experienced people. Confirm the approach with the authorizing official before you decide.
Do we always need an independent penetration tester for CA-8?
No. The base CA-8 control does not itself require an independent tester. The independent requirement appears in the enhancement CA-8(1), which SP 800-53B Release 5.2.0 selects only in the high baseline, so organizations in lower baselines or with tailored controls may not need it. Even when it applies, the tester must be independent of the people who build and operate the system, and that status should be documented in the assessment plan. Some organizations also choose an independent tester for red team exercises under CA-8(2) or for facility testing under CA-8(3), which have their own scope. Confirm which enhancements your system selects in its baseline and tailoring record with the authorizing official.
How does CA-8 relate to RA-5 and CA-7?
CA-8 is a specialized assessment, while RA-5 covers vulnerability monitoring and scanning and CA-7 covers continuous monitoring. The SP 800-53 catalog lists RA-5 and RA-10 as related controls for CA-8, so the scanning results that RA-5 produces can inform what a penetration tester examines, and the tester's findings can point back to scanning gaps. CA-7 provides the ongoing monitoring cycle that tracks whether findings are closed and whether the system still matches its authorization. In practice, the tools that feed RA-5 evidence, such as vulnerability detection on endpoints or scanner results imported into a findings platform, help show what was already known before a penetration test. Penetration test results remain distinct evidence, and they should be recorded in the plan of action and milestones where weaknesses remain open.
What should we ask an implementation partner before signing a fixed-scope agreement?
Ask for the written scope before anything else, because a fixed-scope agreement is only as clear as the list of systems, components, exclusions and test types it covers. Ask which deliverables you receive, such as the assessment plan, rules of engagement, penetration test report, remediation tracking and retest evidence, and who signs each one. Ask how the partner will handle the defined frequency, whether they will support CA-8(1) independence, and how findings flow into your plan of action and milestones. Confirm who owns the test data, how sensitive credentials are handled, and what happens if scope changes during the work. Remember that DeployOpen prepares systems, controls and evidence for assessment but does not issue reports or certifications, so you still need an independent assessor or the authorizing official to accept the results. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen prepares CA-8 penetration testing evidence
DeployOpen plans, implements and documents the self-hosted open-source platforms that support CA-8 penetration testing inside your own infrastructure. We prepare systems, scope, test records and evidence for your assessment, while your organization owns the control and an independent assessor or tester produces the findings and reports.
How we scope
- Agree in writing which systems or components fall inside the defined penetration testing scope.
- Confirm the testing frequency your organization defines for each system and the rules of engagement.
- Record which tests are internal and which require an independent testing agent or team.
How we build
- Deploy self-hosted vulnerability management and findings tools in your cloud accounts or data centers.
- Configure DefectDojo to import tester reports and deduplicate findings across repeated test cycles.
- Connect scanner output from Wazuh, Fleet or Greenbone to the findings register that testers and assessors reference.
How we hand over
- Deliver the penetration test plan, scope record, rules of engagement and test-cycle schedule as written documents.
- Store penetration test reports, retest results and remediation tracking in a format your assessor can examine.
- Document how findings feed the plan of action and milestones, with named owners and status for each item.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask us to confirm which tool capabilities, such as report formats and deduplication, match your environment before scoping.
