What CIS Safeguard 18.5 internal penetration tests require
Safeguard 18.5 requires periodic internal penetration tests based on program requirements, run no less than annually, and each test may be a clear box or an opaque box test. If you are an IG3 enterprise, or you are preparing evidence for an assessor, this safeguard asks for a dated record of internal tests that were planned under your testing program and carried out at least once every twelve months. It is the internal counterpart to Safeguard 18.2, which covers external tests. The external test shows what an outside attacker can reach; the internal test shows what someone already inside the network, whether a compromised account, a malicious insider or a foothold from a phished workstation, can move to next. The risk it addresses is lateral movement across flat or poorly segmented networks and detection gaps that only appear once an attacker is past the perimeter. The CIS Controls Assessment Specification measures 18.5 at zero and fails it when more than twelve months have passed since the last internal penetration test. It also lists Safeguard 18.1, the penetration testing program, as a prerequisite. In practice, that means an assessor will ask for the program document that defines scope, frequency and remediation routing, and then for the most recent internal test report that falls inside it. Confirm with your assessor which report dates and sign-off formats they accept before the test cycle starts. Three things usually make this hard. The first is keeping the schedule: a test that slips by a few weeks at the end of the year can break the twelve-month window, so calendar it against the last report date rather than the calendar year. The second is scoping internal segments: teams often disagree on whether to include flat user subnets, server zones, management networks and cloud VPCs, and an unclear boundary leads to tests that cannot be cited as covering the enterprise. The third is getting tester access: internal testers need network placement, test accounts for clear box work, and a named contact who can approve activity that may trip monitoring. Settle these three decisions in writing before the test window opens.
Which internal networks, assets and teams fall under 18.5
Safeguard 18.5 is an IG3 safeguard, so its scope should follow the penetration testing program set under Safeguard 18.1 rather than a one-off list. The decisions below determine how much testing work is needed and whether an annual internal test covers the places an attacker would actually move.
Internal network segments in scope
List every internal network segment that holds enterprise assets, including user, server, management and guest networks. Each segment adds hosts, routing paths and credentials to test, so the count of segments drives the number of test paths and the time needed per round. Record which segments are excluded and the reason, since an excluded segment that later gains access to sensitive data becomes a gap at the next assessment.
Enterprise assets in the Network class
Safeguard 18.5 sits in the Network asset class, so switches, routers, firewalls, wireless controllers and VPN concentrators are core targets rather than background infrastructure. Confirm which network devices and their management interfaces are reachable from each segment. Device count and firmware variety affect effort, and devices with management planes exposed internally deserve explicit test cases.
Identity systems and directories
Directory services, authentication servers and privileged access tooling are often the fastest route through an internal network. Decide whether testers may attempt credential attacks, Kerberos abuse or privilege escalation against them, and under what limits. Identity scope usually adds the most effort per host, so agree on it in writing before testing starts.
Flat versus segmented networks
On a flat network, an internal test can reach most assets from a single foothold, which widens scope and raises the cost of each finding. On a segmented network, the test must prove that segment boundaries hold, which requires testing from several starting points. Map the segmentation controls before scoping so the test plan reflects the paths that matter, not every possible path.
Regulated data zones
Systems that store or process regulated data, such as payment card data or protected health information, usually need deeper testing than general office networks. Identify these zones, their data flows and their owners, and decide whether the test should reach them from both user and server positions. Mixing regulated and unregulated zones in one scope should be a deliberate choice, with the reasoning recorded.
Third parties with internal access
Contractors, managed service providers and vendors with VPN accounts, jump hosts or direct network connections extend the internal attack surface. Confirm which third-party accounts and connections fall in scope, who authorizes testing against them, and how their own contracts treat testing. Coordinate these items with the service provider management program so that third-party access is tested under the same rules as employee access.
Clear box or opaque box: choosing the internal test approach
A clear box test, sometimes called white box, starts with the tester holding information about the target. That information may include network diagrams, asset inventories, architecture documents, configuration files, source code, or credentials for one or more accounts. The tester uses this material to reach areas that an outsider would have to discover slowly, so the test concentrates on depth: whether a known segment, service or privilege level can be abused, and what a misconfiguration allows once an attacker is inside.
- Starting material: Typically documentation, architecture and sometimes credentials, which the program owner must decide and record in the scope.
- Coverage insight: Shows whether documented controls, segmentation and privilege boundaries hold in practice, including areas the documentation says are protected.
- Evidence produced: A scope record listing what was provided, test paths attempted, findings with reproduction steps and affected assets.
- Limitation to record: Results reflect what the tester was given, so gaps in the supplied documentation can hide gaps in the environment.
- Access handling: Credentials and documents should be issued, logged and revoked under the program's rules.
Before you accept a clear box report, check that the document lists exactly what the tester received and that the findings trace back to that material.
An opaque box test, sometimes called black box, starts with little or no internal knowledge. The tester works from what an intruder with a foothold on the internal network could observe: live hosts, open services, responses from applications and the behavior of authentication and access controls. Because discovery is part of the work, the test shows how easily an attacker could map the environment and which assets are reachable from a given starting point.
- Starting material: Usually only the network position or a standard user account, with the target scope and rules of engagement.
- Coverage insight: Shows what is visible and reachable from the chosen starting point, which can reveal exposed assets that nobody listed in an inventory.
- Evidence produced: Discovery results, a record of the attack path, findings with reproduction steps and the timeline of the test.
- Limitation to record: A test that finds little may reflect a narrow starting position or time limit, so the report should state the starting point and the boundaries.
- Reproducibility: The attack path and tool output should be detailed enough for the team to retest after remediation.
Before you accept an opaque box report, confirm the starting position used and whether the scope excluded any network segment that the program requires to be tested.
Many programs run both approaches, either in separate exercises or within one engagement that moves from opaque discovery to clear box depth. The combined approach lets the tester find what an intruder could discover, then uses supplied knowledge to examine the paths that matter most. It also helps the program measure whether its documentation matches the environment, because differences between the two results often point to inventory or configuration drift.
- Sequencing: A phased engagement might start opaque, then provide documentation or credentials once discovery is complete, with each phase recorded separately.
- Coverage insight: Compares what discovery found with what the documentation lists, which can expose assets missing from the inventory.
- Evidence produced: Separate records for each phase, plus a reconciliation of discovered assets against the documented ones.
- Planning cost: More scoping and coordination, since each phase needs its own rules, access handling and reporting.
- Program fit: Suits enterprises that set several objectives in their 18.1 program, such as validating documentation and measuring depth.
Before you commit to a combined model, confirm with the testing provider how each phase is documented and how the two sets of results will be reconciled.
How an assessor tests Safeguard 18.5
This table compares what an assessor checks for Safeguard 18.5, the evidence requested for each check and the findings that most often fail it. Read it as a pre-assessment checklist: the organization owns the control, and the assessor reviews records and samples to confirm the test program operated as documented.
| Assessment area | Test approach | Evidence requested | Common findings |
|---|---|---|---|
| 12-month measurement rule | Compare the date of the most recent internal penetration test against the assessment date. The Safeguard is measured at zero and fails if more than twelve months have passed. | Dated final reports for each internal test, plus the schedule showing the next planned test. | Last test older than twelve months, or a schedule that lapsed after one cycle with no replacement date. |
| 18.1 prerequisite | Confirm a documented penetration testing program sets the frequency, scope and limitations that 18.5 depends on. | Approved program document naming internal test frequency, scope, rules of engagement and owners. | Program exists but never states an internal test frequency, or was not approved by management. |
| Internal and clear or opaque box scope | Confirm the tests ran from inside the enterprise network and record whether testers had credentials (clear box) or no prior knowledge (opaque box). | Scope statement, network ranges or segments tested, and the test type recorded in each report. | Tests run only from an external vantage point, or the report does not state the box type. |
| Segment coverage | Compare the tested segments against the network diagram and asset inventory to see whether internal zones were skipped. | Asset or segment list in scope, with exclusions and the reason for each exclusion. | Sensitive segments, management networks or user subnets absent from scope without a documented reason. |
| Tester qualifications | Check that the people or firm performing the test have documented skills and are independent of the systems they test where the program requires it. | Tester roles, certifications or experience records, and the engagement letter or statement of work. | No record of who tested, or testers who also administer the systems under test without disclosure. |
| Report dates and retest results | Check that findings are dated, that remediation was tracked and that retests confirmed closure of high-impact issues. | Findings register with dates, retest evidence and the remediation ticket linked to each finding. | Reports list findings but no retest results, or retests cover only some findings. |
How to run internal penetration tests on a 12-month cycle
This sequence turns Safeguard 18.5 into a repeatable cycle: a program that sets the rules, a scoped and authorized internal test, findings routed into remediation, and a booked date for the next test before the twelve-month limit. Each step ends with a document or record an assessor can inspect.
Confirm the 18.1 program and test frequency
Start by checking that the penetration testing program from Safeguard 18.1 exists and names internal testing as a required activity. The program should set the frequency, which Safeguard 18.5 requires to be no less than annually, along with the owner, the test types permitted and the remediation routing. The security lead or CISO approves it, and the approved program is the reference every later step cites. Done when the program document shows an internal test cadence and an accountable owner.
Define internal scope and rules of engagement
Write the internal scope as a list of network segments, subnets, enterprise asset groups and user populations to be tested, and state what is excluded, such as production safety limits or systems owned by service providers. The rules of engagement cover permitted techniques, testing windows, data handling, stop conditions and emergency contacts. Legal, the system owners and the security lead sign the document before testing begins. Done when a signed scope and rules of engagement exist and every in-scope asset owner has acknowledged them.
Choose clear box or opaque box testing per scope
Decide, segment by segment, whether testers receive architecture diagrams, credentials and configuration details (clear box) or start with only network access and no internal knowledge (opaque box). Clear box testing usually reaches more of the attack surface in a fixed window, while opaque box testing better reflects what an insider with limited knowledge could find. Record the choice for each scope item and the reason for it. Done when the test plan lists each segment with its box type and rationale.
Select the tester and confirm independence
Choose who performs the test: an internal team, an outside partner, or a mix in which internal staff cover some segments and a partner covers others. Confirm the testers' skills, their access to the scope, how they handle sensitive findings, and whether the team that operates the systems is kept separate from the team that tests them. Ask any partner for a written statement of scope, methods and reporting format before engagement. Done when a named tester or team is recorded in the signed plan with its responsibilities.
Run the test and capture evidence
Execute the test within the agreed window, following the test plan and rules of engagement. Testers log the commands and tools they run, the systems they reach, the timestamps of activity and any pauses triggered by stop conditions. Open-source tools such as Greenbone Community Edition can support scanning, but scan output alone does not show exploitation, so testers should record the attack paths they validated. Done when the testers deliver a written report covering scope, method, findings with evidence and the tester's limitations.
Triage findings into the 18.3 remediation process
Import the findings into a tracking system, for example DefectDojo, which can deduplicate findings from multiple tools, and assign each one an owner, severity and target date under the vulnerability remediation process. Findings that show a path through internal segments should be routed to the owners of the affected assets. Retest or confirm closure for each item, following the process in Safeguard 18.3. Done when every finding has a tracking record showing owner, status and closure evidence or an accepted risk approval.
Validate security measures and update detections
After the test, review which techniques the testers used and check whether monitoring and prevention controls detected them. Where gaps appear, adjust detection rules and capabilities, and record the changes with the techniques they address. Safeguard 18.4 makes this step an IG3 requirement. Done when the post-test review lists each technique, whether it was detected, and the resulting rule or configuration changes.
Schedule the next internal test
Before closing the cycle, book the next internal test in the security calendar, with a date set comfortably before the twelve-month limit. The Safeguard 18.5 measurement fails once more than twelve months pass since the last internal test, so the date should be fixed in the program's records and owned by a named person. Update the scope if networks or asset groups changed during the cycle. Done when a dated calendar entry and an updated scope draft exist and the test history shows the previous test date.
Evidence that passes an internal penetration test check
An assessor testing Safeguard 18.5 looks for a current internal test on record, traceable back to an approved program and an agreed scope. The six artifacts below link together, so each test should leave a complete, dated trail that the next test can build on.
Approved penetration testing program
The program document from Safeguard 18.1 sets the required frequency, the test types the organization accepts and who owns remediation. Internal testing is measured against it, and CIS lists 18.1 as a prerequisite for measuring 18.5. Check that the document has an approval date, a named owner and a review history, and that it explicitly covers internal tests as well as external ones.
Signed scope and rules of engagement
The signed scope names the internal network segments, asset classes and systems in play, the testing window, and the permitted techniques. It also records whether the test is clear box, with credentials or architecture documents provided, or opaque box, with no prior knowledge. Confirm that the signatories include someone who can authorize access to production systems and that the document predates the test.
Tester report with date and approach
The report should state the test dates, the testers' qualifications, the methodology used and whether the work was clear box or opaque box, as Safeguard 18.5 permits either. Assessors look for enough detail to reproduce the attack paths and for a statement of what was excluded. A report without a date or approach cannot establish when the 12-month window started.
Findings register with remediation status
A findings register lists each finding with severity, affected asset, owner, remediation due date and current status. Findings should trace back to the report and to the vulnerability remediation process. Tools such as DefectDojo can import findings from many scanner formats and deduplicate them, which keeps one register across internal and external tests. Confirm that open items have documented risk acceptance.
Retest and validation records
Retest records show that remediated findings were verified, not just marked closed. For internal tests, pair them with evidence that detection rules were checked against the techniques the testers used, which is the work Safeguard 18.4 describes for IG3. Keep the retest date, the tester or reviewer and the result for each finding.
Schedule showing the next test
A dated calendar entry for the next internal test shows that the program is recurring. Safeguard 18.5 fails when more than twelve months have passed since the last internal test, so the schedule should show the due date of the next test against the completion date of the last one. Assign an owner who receives reminders before the window closes.
What meeting Safeguard 18.5 costs in money and effort
This table lists each cost component of running internal penetration tests under Safeguard 18.5, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written quote and to see which costs your own team can absorb. No prices are given because none are supplied; request figures from each provider against a written scope.
| Cost component | One-time or recurring | What drives it | How to reduce it |
|---|---|---|---|
| Tester fees for internal testing (external engagement) | Recurring, at least once every twelve months | Number and segmentation of internal network zones, test depth (clear box or opaque box), and whether the work includes lateral movement and privilege escalation | Define zones and depth in the written scope, ask for a fixed-scope quote, and reuse the scope document year to year |
| Internal staff time for scoping and remediation | Recurring, each test cycle | Program requirements set under Safeguard 18.1, the number of findings, and how many owners must confirm asset details and rules of engagement | Keep an asset and network diagram current, pre-agree contacts and escalation routes, and route findings into the existing remediation process |
| Tooling and licenses for testers and your team | Recurring, through subscriptions or renewals | Commercial scanner and exploitation tool licenses, seat counts, and whether the provider brings its own tooling or requires yours | Ask which tools the provider supplies, confirm license terms in the quote, and consider open-source scanners where the provider accepts them |
| Open-source tooling that removes license spend | One-time setup, then recurring upkeep | Hosting, configuration, patching and staff skill to run tools such as Greenbone Community Edition for vulnerability scanning and DefectDojo for consolidating findings | Host on infrastructure you already run, document configuration, and confirm with the tester that its methods and reports accept open-source outputs |
| Evidence upkeep | Recurring, after every test | Retaining scope documents, rules of engagement, raw results, findings records and remediation tickets in a form an assessor can sample | Store each test cycle in a single evidence location with consistent naming, and set a retention period in your records policy |
| Retest effort | Recurring, when findings are fixed | Number of open findings, complexity of fixes, and whether the provider charges separately for verification testing | Fix high-impact findings before retesting, batch retests, and ask the provider for retest terms in writing |
| Auditor sampling and walkthroughs | Recurring, at each assessment | How many test cycles fall in the audit period, the depth of documentation requested, and whether the auditor needs a walkthrough of the test methodology | Prepare a single test summary per cycle, keep scope and results linked, and confirm with the auditor which artifacts they will sample |
Open-source tools that support internal test evidence
Safeguard 18.5 asks for internal penetration tests on a set schedule, and the tests produce findings that must be recorded, deduplicated and tracked to closure. The tools below do not replace a penetration test. They help collect continuous evidence between tests, consolidate findings and show an assessor how results moved through the process.
Endpoint vulnerability detection with Wazuh
Wazuh correlates the software inventory each agent collects with its vulnerability repository, or a locally hosted offline copy, to flag weaknesses in operating systems and installed applications on monitored endpoints. Its licence is GPL-2.0-only, so confirm with counsel how your internal use and any distribution of modified code fit that licence. Check that the agents cover the internal network segments in your test scope, and that the offline feed is refreshed on a schedule you can show.
Vulnerable software on enrolled hosts
Fleet matches installed software on enrolled hosts against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. Fleet is released under the MIT licence, which is permissive, but your own build and hosting choices still need review. Use its results as a dated record of exposure between internal tests, and confirm which sources apply to the operating systems in your estate.
Finding triage in DefectDojo
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 deduplicates them using per-tool hashcode fields. It is licensed under BSD-3-Clause. Use it as the register where internal test findings, scanner output and remediation status sit together. Confirm that your tester's report is loaded as a finding source and that deduplication does not merge distinct issues.
Scheduled scans with Greenbone Community Edition
Greenbone Community Edition, built on OpenVAS, uses gvmd to schedule scan tasks and store results in PostgreSQL, while users manage permissions and review results in the Greenbone Security Assistant web interface. It is licensed under AGPL-3.0-or-later, which carries network-use obligations if you modify and expose the software to others. Record who runs each scan, the targets and the schedule, since these entries show the testing cadence an assessor will ask about.
Your team, an implementation partner and the auditor
Your organization owns Safeguard 18.5. The control asks for periodic internal penetration tests at least annually, and it is measured against your own penetration testing program, so the program has to be run by people accountable inside the business. Under Safeguard 18.1, your team sets the program: scope rules, test frequency, limitations, contacts, remediation routing and retrospectives. Your team approves each internal test scope before it starts and decides how findings are prioritized against the business.
- Program ownership: Maintain the penetration testing program under Safeguard 18.1, including who may authorize a test and who receives results.
- Scope approval: Sign off on which internal network segments, assets and clear box or opaque box conditions apply to each test.
- Remediation: Route findings into the vulnerability remediation process under Safeguard 18.3 and track them to closure.
- Risk acceptance: Decide in writing which residual risks are accepted, by whom and until when.
- Tracking the annual cycle: Keep a dated record of the last internal test so the twelve-month limit in the assessment specification is never missed.
Check that your named owner can show the approved scope, the remediation tickets and the acceptance records for the most recent test without help from a third party.
An implementation partner prepares the systems, documents and evidence that let your team run and prove Safeguard 18.5. DeployOpen, for example, works inside your own infrastructure and can prepare scope documents, evidence folders, tooling and the test calendar, and can run internal penetration tests under a fixed written scope. The partner does not decide what risk you accept, does not set your program requirements, and does not issue any report or attestation about your control.
- Scope documents: Draft the internal test scope, rules of engagement and clear box or opaque box assumptions for your approval.
- Evidence set-up: Organize test plans, raw tool output, retest results and sign-offs into a folder structure an assessor can sample.
- Tooling: Configure and host self-managed scanning and tracking tools in your environment so findings are stored and deduplicated.
- Test calendar: Maintain the schedule that keeps each internal test within twelve months of the previous one.
- Fixed-scope testing: Carry out the internal tests themselves, plus retests after remediation, against an agreed scope.
Ask any partner to state in writing which parts of the work it performs and which remain with your staff, and confirm it does not issue assurance to third parties.
An independent auditor, assessor or certification body is the only party that tests whether Safeguard 18.5 is operating and issues any report or attestation. The auditor reviews your program documents, the approved scopes, the dates of internal tests, the findings and remediation records, and a sample of the tests themselves. Because the auditor must stay independent, it cannot design the controls or prepare the evidence it then judges.
- Record review: Checks the program under Safeguard 18.1 and confirms the scope and dates of each internal test.
- Sample testing: Selects tests and traces their findings through remediation and retest.
- Independence: Works without authoring the scope, the tooling configuration or the evidence folders it reviews.
- Report or attestation: Issues the conclusion, which is the only formal assurance output.
- Exceptions: Records any gap, such as a test older than twelve months, for you to address.
Before engaging an auditor, confirm which framework and assessment version it will use, how it will sample your tests and what it needs from you in advance.
Some work is usually outsourced because it needs specialist skills or capacity, while ownership and judgment stay in-house. The test itself, retests and evidence set-up are the most common items handed to a partner. Decisions about ownership, remediation and risk acceptance should remain with your organization, because the assessment depends on them being yours.
- Usually outsourced: The internal penetration test execution against an agreed scope.
- Usually outsourced: Retesting after remediation to confirm fixes hold.
- Usually outsourced: Building the evidence folders, tool configuration and test calendar.
- Keep in-house: Program ownership, scope approval and the choice of clear box or opaque box conditions.
- Keep in-house: Remediation priorities and every written risk acceptance.
Ask each partner for a quote that lists these items separately, so you can see what is one-time setup and what recurs with each annual test.
Questions buyers ask about internal penetration tests under 18.5
Does safeguard 18.5 apply to IG1 or IG2 organizations?
No. Safeguard 18.5 sits in Implementation Group 3 only, so it is not part of the IG1 or IG2 baseline. IG3 is the group CIS aims at enterprises with security specialists and regulated, sensitive assets facing sophisticated, targeted attacks. An IG1 or IG2 organization still benefits from the external testing in 18.2 and the program in 18.1, and should confirm with its assessor or regulator whether internal testing is expected under another framework. Check the CIS Controls Navigator for mappings that may pull the requirement into a different obligation.
Is a clear box or opaque box internal test enough for 18.5?
Either can satisfy the safeguard, because 18.5 allows clear box or opaque box tests. A clear box test gives the testers documentation, configuration and credentials, which usually makes coverage deeper and faster. An opaque box test gives them little prior knowledge, which shows what an insider or compromised account could reach without help. The choice should follow the objectives in your penetration testing program under 18.1, and the test type should be recorded in the scope document so an assessor can match the work to the requirement.
How often must internal penetration tests run, and what happens after 12 months?
The safeguard requires periodic internal tests based on program requirements, no less than annually. Under the CIS Controls Assessment Specification, the measure fails once more than twelve months have passed since the last internal penetration test. Your program may set a shorter cycle after significant changes to the network, new internal systems or a recent incident. Record each test date, scope and report so the last-test date can be shown on request. Confirm the exact measurement rules in the Assessment Specification for Safeguard 18.5.
Can our internal security staff run the internal penetration test themselves?
The safeguard does not require an outside firm, but it does require that the tests follow your penetration testing program, so internal staff can run them if they have the skills, tooling and independence the program calls for. Common concerns are whether testers are independent of the teams they assess, whether they can document findings to the standard your assessor expects, and whether the work is sustainable each year. Many organizations keep routine scanning in-house and bring in an external specialist for deeper, scenario-based work. Decide this in the program and write it down before the engagement starts.
What drives the cost and effort of an internal penetration test?
The main drivers are the number of network segments and assets in scope, the test type (clear box or opaque box), the depth of exploitation expected, the number of attack paths to validate, and how much reporting and retesting is required. Cost has two parts: the people doing the work and the tooling or licenses used. Recurring costs come from the annual cycle, plus any retesting after remediation. DeployOpen does not publish prices. A quote follows from a written scope that states these drivers, so ask each bidder to price the same segments, test type and deliverables.
What does the internal test need from our team?
Expect to supply a named sponsor, a scope document, network diagrams, asset and account lists for the systems in scope, rules of engagement, and contacts for emergency stops. For clear box work, the testers also need documentation and access that you approve in advance. Your operations team should be ready to answer questions and to review any disruptive activity before it runs. Keep the request list short and agree on it in writing so that the test itself is not delayed by missing information.
How long does preparation take before an internal penetration test starts?
Preparation time depends on how quickly you can produce the scope, approvals, access and contacts listed above, and on whether the program under 18.1 already defines these items. The timeline is not fixed by any supplied source, so ask your provider for a schedule in the written scope and confirm the window with your change management and legal teams. Organizations that already have a current program and an up-to-date asset inventory usually prepare faster than those starting from scratch.
How DeployOpen prepares internal penetration test evidence
DeployOpen helps organizations set up the systems, scope documents and evidence records that support internal penetration tests under Safeguard 18.5. The organization owns the test program and its findings, and DeployOpen prepares the environment and records so that the work can be shown to an assessor.
How we scope
- Each engagement starts with a written scope that names the internal network segments, asset classes and test approach for Safeguard 18.5.
- The scope records whether testing is clear box or opaque box and which access, credentials and assumptions the testers receive.
- Scope also states the test window, the dependency on the Safeguard 18.1 program requirements and the annual cadence the organization must keep.
How we build
- We prepare the open-source tooling needed to support internal testing, such as scanning and findings management platforms, in the client's own infrastructure.
- Scan and test results are routed into a findings store that deduplicates records and keeps a traceable history for each test cycle.
- Access, logging and data handling for the test environment are configured so that the test activity itself can be reviewed later.
How we hand over
- Deliverables include the written scope, test records, a findings register and a dated log showing when each internal test was performed.
- We document how the evidence maps to the twelve month test interval that the assessment specification checks for this Safeguard.
- Handover covers the runbooks, administrator access and the list of items the organization must confirm with its own internal or external testers.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement is delivered.
- We can prepare the environment and records before each annual cycle so that the next internal test is scheduled and documented on time.
- Questions about whether a specific assessor will accept a given evidence format should be confirmed with that assessor before work starts.
