Internal network penetration testing

Internal network penetration testing: what it proves and why regulators ask for it

If you are reading this because a PCI DSS assessment, a customer security questionnaire, an insurer or a board member has asked whether your internal network has been tested, the short answer is that an internal penetration test shows what an attacker who already has a foothold inside your network could reach, take and disrupt. It answers a question that an external test cannot: once someone is past the perimeter, how far can they move, and what stands between them and the systems that matter most. PCI DSS v4.x requirement 11.4.1 defines internal penetration testing as testing from inside the network, both inside the cardholder data environment (CDE) and into the CDE from trusted and untrusted internal networks. NIST SP 800-115 describes the same activity as a planned, authorized test of techniques used to validate vulnerabilities, with management approval and written rules set before any work starts.

The risks this test addresses fall into four groups. Lateral movement asks whether a compromised workstation or low-privilege account can reach servers, management interfaces and administrative channels it has no business reaching. Credential exposure looks for passwords, hashes, tokens and service account secrets left in places an attacker can read, such as scripts, file shares, configuration files or cached sessions. Segmentation weaknesses test whether the firewalls, VLANs and access rules that are meant to isolate sensitive environments actually do so. Paths to critical systems trace the combined route, from a user endpoint through identity, trust relationships and shared services to a domain controller, a payment application or a backup repository. Each of these is a question about how the network behaves in practice, not only how it is documented.

The difference from the external test is the starting point and the trust assumed. An external test, covered in its own sibling topic, begins with what an internet attacker can see and reach. An internal test assumes the attacker has already gained a foothold, usually through a phishing email or a compromised device, and measures what happens next. Because the internal environment contains far more hosts and trust relationships, the work is broader in scope. Before commissioning one, confirm with the provider whether the test is overt or covert, which NIST SP 800-115 distinguishes, and whether the rules of engagement cover the CDE boundary, any segmentation you rely on for PCI DSS scope reduction, and the production systems that testers may touch.

What can be in scope for an internal test

An internal test is only as useful as its boundaries. The decisions below set which segments are reachable, which systems count as the cardholder data environment, where the tester starts and what they may touch, and they are recorded in writing before any testing begins. NIST SP 800-115 treats this as the planning phase, where rules are identified and management approval is documented.

Network segments and subnets

List every segment, VLAN and subnet the test may reach, along with the segments that are explicitly excluded. Ask which ranges hold production databases, backup systems, management interfaces and industrial or medical devices that need a different change window. For each segment, agree whether the tester may run active discovery, authenticated scanning or only passive observation. Ask the provider to show how the scope list will be checked against your current network diagrams and asset inventory.

Cardholder data environment boundaries

Define the CDE and the systems that connect to it, then decide which paths the test must attempt: from trusted internal networks, from untrusted internal networks such as guest or contractor ranges, and from inside the CDE itself. PCI DSS requirement 11.4.1 describes these three views. Confirm with your assessor whether segmentation testing under requirement 11.4.5 will run as part of the same engagement, and whether the test will cover the systems that the segmentation controls are meant to isolate.

Assumed breach or user-level starting point

Choose where the tester begins. An assumed-breach start gives a compromised host or standard user account and asks how far an attacker could go from there. A start from a supplied user account on a workstation tests whether ordinary access leads to privilege. Each choice answers a different question, and the choice drives both the effort and the value of the findings. Agree in writing which starting host or account is used, who prepares it, and how it is removed afterward.

Credentials and accounts supplied

State which credentials, if any, the tester receives: none, a standard domain user, a local administrator on one host, or a service account. Each supplied account should have an owner, an expiry date and a logging trail. Confirm whether password spraying, credential reuse checks or hash-based attacks are permitted, and against which directories or systems. Ask for the list of accounts that will be locked out or disabled during testing, and agree who is notified if an account lockout affects production users.

Rules of engagement and production safeguards

The rules of engagement are the written contract for the test. NIST SP 800-115 provides a template in Appendix B covering testing windows, source addresses, prohibited techniques, escalation contacts, data handling and stop conditions. Agree which activities are off limits, such as denial of service or exploitation of fragile operational systems, and who can halt the test. Confirm that no scope change happens without written approval from the named sponsor.

How an internal engagement runs, phase by phase

The sequence moves from agreed rules and management approval through discovery and validation of weaknesses to a report and a retest, so the client can see what an attacker inside the network could reach and confirm that the fixes hold.

Agree rules of engagement and approval
The planning phase, as NIST SP 800-115 describes it, identifies the rules that govern the test and records management approval before any traffic is sent. In practice this covers the in-scope network segments, the cardholder data environment if one is in scope, the systems that must not be disrupted, the testing window, emergency contacts and the stop conditions. DeployOpen works from a written scope and rules of engagement, usually based on the template in Appendix B of that guide, and the step is complete when the client has signed both. Ask who on your side can halt testing and how quickly they can be reached.
Provide the foothold and access model
Before testing starts, the client agrees how the tester enters the network. The options range from a supplied standard user account or a device placed on a chosen subnet to a plain network connection in a designated location. Each option changes what the test shows, so the choice should match the threat being assessed. The step closes when access is confirmed in writing, the accounts and source addresses are logged, and the client's security operations team knows the test is running if the engagement is overt. Confirm how credentials are stored and removed at the end.
Map hosts, services and exposure
Discovery is the first technical phase. The tester identifies live hosts, open ports and running services across the agreed ranges, and performs vulnerability scanning to build a baseline of likely weaknesses. This is the target identification and analysis group in NIST SP 800-115, and it is largely passive or low-volume so that production systems are not overloaded. The output is an inventory of hosts, services and version details that the client can compare with its asset register. Discrepancies between the two, such as unknown hosts or unexpected services, are recorded as findings in their own right.
Validate weaknesses and trace lateral movement
Using the discovery output, the tester checks which weaknesses are real and how far access can travel. This is the target vulnerability validation group in NIST SP 800-115. Typical objectives include exposed or reused credentials, weak service configurations, trust relationships that let one host control another, and segmentation gaps between user networks, server zones and the cardholder data environment. Testers record each path step by step, but the report describes weakness categories and the evidence collected, not reusable attack instructions. The step is complete when each path has been confirmed or ruled out and the business impact is clear.
Stop safely and record production impact
Throughout validation, the tester watches for effects on production systems and follows the stop conditions in the rules of engagement. If a fragile service slows, an account locks out or a segment behaves unexpectedly, testing pauses and the client is told. The engagement log records each pause, the reason and the time it resumed. The step closes when the client has the log and agrees that any disruption is documented, so the report can state what was tested and what was deliberately left alone.
Deliver the report and remediation plan
The reporting phase produces a written report that covers the scope and rules as agreed, the methods used by group, each validated finding with its evidence and affected systems, and the paths to critical assets. Each finding carries a remediation recommendation and a suggested priority. The report also states what was not tested. The step is complete when the client has reviewed the draft, the factual points are corrected and the final version is issued. Ask in advance whether the report must map to a specific framework or control set, such as PCI DSS requirement 11.4.1 or 11.4.5 or CIS Safeguard 18.5, so the structure suits the auditor.
Retest and confirm the fixes
After the client remediates, the tester repeats the checks that proved each finding and records whether the fix holds. Retest is a separate, scoped piece of work, and it should be agreed when the original engagement is scoped. The output is a retest statement that lists each finding as closed, partly closed or open, with the evidence behind each status. This is also the point where changes trigger new testing, since PCI DSS requires internal testing after significant infrastructure or application changes. Confirm with DeployOpen how retest is priced and timed in the written quote.

How internal testing changes by environment

A flat network has few internal boundaries, so a foothold on any workstation can often reach file shares, print services, management interfaces and domain controllers. The test emphasizes lateral movement and credential exposure: how far a standard user account can travel, whether cached or reused credentials exist, and which paths lead to privileged identities. Because the attack surface is broad, the scope is usually defined by business-critical systems and a set of representative starting points rather than every host.

Starting foothold: Agree whether testing begins from a standard user workstation, a contractor laptop or a guest-adjacent segment, and who supplies the account.
Credential exposure: Confirm which credential stores, shares and management consoles are in scope for review.
Critical targets: List the domain controllers, backup servers, hypervisors and administrative jump hosts that define success.
Production limits: Agree which scanning rates, account lockout thresholds and services must not be touched.
Stop conditions: Define who is called if a service degrades and who approves continuing.

Before testing, confirm written authorization, named technical contacts, a current asset inventory and the backup and restore state of any system that could be affected.

Weakness categories internal testing validates

This table lists the weakness categories an internal test validates, what each one looks like inside a typical network, and why it matters for cardholder data and critical systems. Read each row as a question to ask during scoping: if a category is in your environment, it should be in the agreed test plan. The main takeaway is that a single initial foothold matters less than the paths it opens toward systems that carry regulated data.

Weakness category	What it looks like in this target	Why it matters
Credential exposure and reuse	Passwords or hashes stored in scripts, configuration files, shared drives or memory on user and server hosts, and the same local or service credentials reused across many machines	One exposed credential can grant access well beyond the host where it was found, often without any exploit
Lateral movement paths	Chains of trust between workstations, servers and administrative tools that let access move from a low-value host toward systems with more privilege	Each hop may look minor on its own, but the full chain determines how far an intruder could reach
Segmentation gaps between the CDE and out-of-scope systems	Firewall rules, VLANs or cloud routing that allow traffic from general corporate or development networks into the cardholder data environment	PCI DSS requirement 11.4.5 asks for segmentation to be tested, and a gap can widen the scope of the whole assessment
Excessive trust between hosts	Shared service accounts, broad host-based trust, or management connections that let one system administer many others without strong checks	Trust relationships are often undocumented, so they quietly extend the reach of any compromised host
Exposed management interfaces	Administrative web consoles, hypervisor panels, backup servers, network device management and out-of-band controllers reachable from user subnets	Management planes control many systems at once, so exposure here carries a disproportionate impact
Unpatched services reachable from inside	Internal services with known vulnerabilities, outdated components or default settings that are not visible from the internet but are reachable from user networks	Internal exposure is frequently the difference between a contained incident and a broad one
Paths to critical systems	Documented or discovered routes from the test foothold to domain controllers, payment applications, databases and backup repositories	This is the end-to-end result a buyer should see, showing which systems an attacker could reach and how

How PCI DSS segmentation testing fits into the internal test

Segmentation testing is a separate PCI DSS obligation from the internal penetration test, although the two share tooling and access. Requirement 11.4.5 asks for penetration tests of the segmentation controls at least every 12 months and after changes, with the goal of confirming that segmentation isolates the cardholder data environment (CDE) from every out-of-scope system. Requirement 11.4.6 raises that frequency to every six months for service providers. The internal test under 11.4.1 asks a different question: what an attacker already inside the network can reach, including paths into the CDE from trusted and untrusted internal networks. A segmentation test asks whether the boundary itself holds. Ask your provider to document which of the two activities each finding belongs to, because the assessor will look for that mapping.

The overlap is large. Both tests start from a foothold in the internal network, both examine flows from user subnets, guest or management networks, and both test firewall rules, routing, VLAN boundaries and jump hosts. They differ in the target and the pass condition. For segmentation, the test must demonstrate that the out-of-scope systems cannot reach the CDE, so the scope list, the network diagrams and the firewall rule base must agree with what is observed. Confirm with the business who owns each segment, which systems are in scope, and whether any shared services such as Active Directory, logging, backup or patching cross the boundary. Those shared services are where segmentation most often fails in practice.

The assessor will expect evidence that ties the test to the environment as it stands. Ask for the segmentation methodology, the defined boundary and its justification, the list of tested paths with source and destination ranges, screenshots or logs showing blocked and permitted traffic, and a clear statement of the test date relative to the most recent significant change. Also ask whether the segmentation test was performed by a qualified tester with organizational independence, as 11.4.2 and 11.4.3 require for penetration testing generally. DeployOpen prepares systems and evidence for compliance assessments but does not issue reports or attestations; the QSA or the acquiring bank's assessor makes that determination.

What drives the cost and duration of an internal test

This table compares the factors that change the price and length of an internal network penetration test, who carries each cost, and what the buyer can do to keep effort proportionate. Read it before requesting a quote, because the same scope items appear in the written proposal and determine the number of testing days. The main takeaway is that a quote is only comparable to another when both state the starting access, segments, CDE boundary, rounds and retest terms.

Cost driver	Why it changes effort	How to keep it proportionate
Network segments and subnets	Each segment needs its own discovery, reachability checks and validation of filtering between zones, so effort grows with the number of boundaries tested.	Agree a segment inventory with the client up front and test the zones that hold identity, management or cardholder data first.
Number of hosts and identity stores	Host counts drive scanning and validation time, while each domain controller, directory or credential store adds review of its own trust and access paths.	Limit host sampling to representative systems per build, and confirm which identity stores are in scope before the start date.
Starting access: assumed breach or supplied low-privilege account	An assumed breach start skips some early work but requires the tester to reach each target from a chosen position. A supplied low-privilege account shortens initial access but needs account setup and a defined privilege level.	Choose one starting model in the written scope and state the account type, its privileges and how credentials are issued and revoked.
CDE scope and segmentation boundary	Testing into the cardholder data environment from trusted and untrusted internal networks, plus segmentation checks, adds targets and evidence requirements under PCI DSS requirements 11.4.1 and 11.4.5.	Reduce the CDE to documented system boundaries and confirm the segmentation design before testing so effort is spent on real boundaries.
Test depth	A validation-only test confirms exploitable paths. A deeper test adds lateral movement chains, credential exposure review and impact analysis, which takes more time per path.	Agree depth by objective, such as proving a path to a named critical system, and exclude broad exploitation that adds no assessor value.
Number of rounds	A first round reveals most paths. Additional rounds after fixes or changes repeat part of the work, and each round needs its own planning and reporting.	Plan a defined retest round within the initial quote so follow-up work is not priced as a new engagement.
Production constraints and change windows	Testing limited to maintenance windows, rate limits on scanning, or required monitoring and rollback plans extends elapsed time and adds coordination work for both teams.	Document approved test windows, prohibited actions and a contact path for stopping tests in the rules of engagement, as NIST SP 800-115 recommends.
Retest	Retesting confirms that remediation closed each validated path. Its effort depends on how many findings are retested and whether fixes change architecture.	Ask whether retest is included, how many findings it covers and the time window for submitting fixes.
One-time versus recurring costs	Scoping, rules of engagement, testing and reporting are one-time for each engagement. Annual or change-driven retests recur, and continuous testing is available as a retainer.	Ask the provider to separate the one-time engagement from any recurring retest or retainer lines in the quote.

Which compliance frameworks expect internal penetration testing

Does PCI DSS require internal penetration testing?

Yes. PCI DSS v4.x requirement 11.4.1 defines internal penetration testing as testing from inside the network, covering the cardholder data environment (CDE) and paths into the CDE from both trusted and untrusted internal networks. Requirements 11.4.2 and 11.4.3 require internal and external tests at least once every 12 months and after any significant infrastructure or application upgrade or change. The tester may be a qualified internal resource or a qualified external third party with organizational independence, and that tester does not need to be a QSA or ASV. Your assessor decides whether your tester's qualifications and independence meet the requirement, so confirm that with them before testing starts. Segmentation testing under requirement 11.4.5 is a separate obligation that runs alongside this one.

What does PCI DSS segmentation testing add to an internal test?

Segmentation testing checks that your controls actually isolate the CDE from out-of-scope systems. Requirement 11.4.5 requires these tests at least every 12 months and after changes, and requirement 11.4.6 raises the frequency to every six months for service providers. An internal test that starts from a non-CDE network is a common way to exercise segmentation, but the two are not identical: a segmentation test must confirm isolation specifically. Ask your assessor whether they expect a separate segmentation report or whether it can be part of the internal test deliverable.

What does CIS Controls Safeguard 18.5 expect for internal testing?

CIS Controls v8.1 Safeguard 18.5 asks for internal penetration tests at least annually. The safeguard allows the test to be clear box, where the tester receives documentation and architecture details, or opaque box, where the tester starts with little or no internal knowledge. Choose the approach based on what you want to learn. Clear box testing usually covers more configuration ground in less time, while opaque box testing shows how far an attacker with limited information could get. The safeguard does not define a test depth, so agree the depth and the reporting format in the written scope. Whether a CIS-aligned program satisfies your organization's own review depends on the reviewer, so confirm that before you buy.

Do customer security reviews require an internal penetration test?

Many enterprise and public sector customers include internal testing in their third-party security questionnaires or contract schedules, particularly when a vendor will host their data or connect to their network. The requirement usually appears as a request for a recent test summary, its date, the scope and the remediation status of findings. Customers rarely accept a test they cannot read, so plan for an executive summary they can share and a full technical report for your own team. Ask each customer whether they need a test performed by an independent party, how recent it must be and whether they expect a retest of critical findings. Their security team decides whether your evidence is acceptable.

Do cyber insurers ask for internal penetration test results?

Cyber insurers increasingly ask about security testing during underwriting and renewal, and some policies set conditions tied to specific controls. Insurers typically want to know whether testing happens, how often, who performs it and whether serious findings were fixed. The wording of each policy varies, so have your broker or legal team check what the policy requires before you rely on an internal test as evidence. Ask the insurer what documentation they accept, such as a summary letter from the tester, and whether they require a particular test type or depth. The insurer's underwriting team decides whether the evidence meets its conditions.

Who decides whether an internal penetration test meets a framework?

The assessor, certification body, regulator or customer decides whether a test satisfies their requirement. DeployOpen plans, performs and documents security testing, and prepares evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make the acceptance decision. Before testing starts, share the framework requirements with your assessor or customer and get their written view on the tester's qualifications, the test type, the depth and the report format. That conversation saves rework and avoids gaps discovered during the assessment.

How should I plan an internal test to cover several frameworks?

Map each requirement to a single test plan so one engagement can serve several audiences. A practical approach is to list every framework, its test frequency, the trigger events and the evidence each assessor expects. The NIST SP 800-115 guide describes planning steps, including documenting rules of engagement and management approval, which give your assessors a traceable record. Ask your assessor and customers to confirm the shared scope, the required report sections and the retest expectations. Keep the schedule tied to changes as well as calendar dates, since PCI DSS and several customer reviews require testing after significant change.

What you receive and whether it satisfies an auditor or customer

An internal test produces more than a list of findings. The package you receive has to show what was tested, how far access reached, what was validated, and whether fixes held, and it has to be accepted by the people who rely on it. Confirm the format and the acceptance criteria with your QSA or customer before testing starts, not after the report lands.

Executive summary and scope

The executive summary states the overall outcome, the highest-impact paths and the decisions leadership must make. The scope and methodology section lists the network ranges, segments, Active Directory domains and cardholder systems in scope, the access level given to testers, the testing window and the rules of engagement agreed under the approach NIST SP 800-115 describes. Check that the scope section matches the agreed written scope exactly, because an auditor will compare the two.

Attack narrative

The attack narrative explains how the tester moved from the starting foothold to the systems that matter, step by step at a level a defender can act on. It shows which credentials, trust relationships or misconfigurations enabled each move and where detection did or did not respond. Ask for the narrative to name the systems touched and the time each stage took, so your security operations team can compare it with their logs.

Validated findings with severity

Each finding records the affected assets, the evidence that proves the issue was exploited or validated, a severity rating with the rationale behind it, and the conditions required to reproduce it. Findings that were only suspected should be labeled as such and kept separate. Ask the provider to state the rating method in advance, so severity does not shift between drafts.

Segmentation evidence section

Where cardholder data is in scope, a separate section documents each segmentation test: the boundary tested, the source and destination systems, the protocols that crossed or were blocked, and the result. PCI DSS requirement 11.4.5 sets the cadence for segmentation testing, and this section is the evidence an assessor reviews first. Confirm with your QSA whether they want the raw test log, screenshots or both.

Remediation guidance and retest results

Remediation guidance gives a specific fix for each finding, with the owner, the affected configuration and a suggested order based on risk. After you apply fixes, a retest confirms whether each finding is closed and records the results against the original report. Ask whether retest is included in the fixed price, how many retest rounds are covered and how long the provider keeps evidence.

Attestation-style letter of work performed

A letter from the provider can confirm that the testing was performed, the dates, the scope and the methods used. It does not certify your environment, and it does not replace the QSA's assessment or any certification. Ask your QSA or customer to specify the exact wording they accept in advance, and check that the tester's qualifications and organizational independence are described accurately in the letter.

How production risk is managed during internal testing

Production risk in an internal test is controlled before the first packet is sent, through a written rules of engagement agreed by the client's leadership and the testing firm. NIST SP 800-115 treats this as the planning phase, where rules are identified and management approval is documented, and it provides a rules of engagement template in Appendix B that is a sound starting point. For an internal test, the document should name the source addresses the tester will operate from, the network segments and jump hosts in scope, the cardholder data environment if PCI DSS segmentation testing is included, and the test windows in which activity may occur. It should also state which techniques are off limits, such as denial of service, account lockout attacks against privileged accounts, or changes to production directory objects. Ask the provider to show you a sample rules of engagement before you sign the statement of work, and confirm that the named IT contacts can be reached during every window.

Rate limits and stop conditions are where the rules become operational. Agree a ceiling on scanning speed and authentication attempts, since a poorly tuned credential test can lock out service accounts or flood a domain controller's logs. Define stop conditions in advance: a service outage, a monitoring alert that suggests a real intrusion, a finding that exposes data outside the agreed scope, or a request from the client's on-call lead. Decide who has authority to pause testing and how that pause is confirmed in writing. Backup and rollback expectations should also be explicit. Confirm that the systems the tester may touch have current backups or snapshots, that any changes made during validation (such as a test account or a planted file) are logged, and that the tester removes them and reports each one. If accidental disruption occurs, the contract should require immediate notification, a timeline of the affected activity, and a joint review of the root cause.

Overt and covert testing are two different risk and cost profiles, and NIST SP 800-115 distinguishes them. Overt testing is done with the IT staff aware of it, is less expensive, carries less risk and is the more frequently used approach, and it suits most internal assessments tied to PCI DSS or CIS Controls. Covert testing is done without the IT staff's knowledge, but it requires permission from upper management, and it examines the damage an adversary could cause rather than attempting to find every vulnerability. Choose covert testing only when the goal is to measure detection and response, and make sure the executive sponsor, legal counsel and a small, named group of decision-makers know the test is happening and how it will be halted. Whichever model you choose, decide in advance how the security operations team will be told, since a covert test that triggers an unplanned incident response has a cost of its own.

What to check when choosing an internal testing provider

An internal test runs from a foothold inside your network, so the provider sees what your staff and systems expose to a trusted-but-compromised device. The cards below cover what to verify before signing, from segmentation experience and independence to rules of engagement, report quality, data handling, retesting and stop conditions. Confirm each point in writing, not in a sales conversation.

Experience with segmented networks and CDEs

Ask for evidence that the team has tested segmentation boundaries, not only flat internal networks. For PCI DSS work, the provider should be able to explain how it would test from trusted and untrusted internal networks into the cardholder data environment, and how it would confirm that out-of-scope systems cannot reach it. Ask which segmentation methods it uses and how it records what was reachable from each zone. Request a description of comparable work, anonymized, and confirm who would actually perform the test.

Independence from the operating team

PCI DSS requires testers with organizational independence from the people who run the systems being tested. Ask the provider to state in writing that its testers do not administer, configure or report to the teams responsible for the target environment, and that no tester was involved in building the controls under test. Also confirm whether the provider also performs remediation for you, because that can weaken the independence of the retest. Treat a verbal assurance as insufficient.

Written rules of engagement

NIST SP 800-115 treats the planning phase as the point where rules are identified and management approval is documented, with a rules of engagement template in its appendix. Expect a written document that names in-scope IP ranges, permitted techniques, testing windows, named contacts, accounts provided to the tester and excluded systems. Check whether it covers credential handling and what happens if the tester gains access to data beyond what was agreed.

Sample report review

Ask for a redacted sample report before you commit and check whether it shows the attack path, the systems involved, the evidence captured and the business impact in plain language. A useful report separates validated findings from observations and gives remediation steps that your engineers can act on. Confirm that it maps findings to the segmentation or control question your auditor will ask, and that the executive summary is distinct from the technical appendix.

Handling of sensitive data

During an internal test the tester may encounter cardholder data, personal records, credentials and privileged secrets. Ask how the provider limits collection to proof of access, how it stores evidence, where working files reside, how long they are kept and how they are destroyed. Confirm whether evidence is encrypted, who can view it and whether any data leaves your environment. Get these terms into the contract, not only the statement of work.

Retest terms

Retesting confirms that fixes closed the paths that were found. Ask whether retest is included in the fixed price, how many retest rounds are covered, what window applies after the report, and whether the retest uses the same methodology and access as the original test. Clarify whether the provider will issue written retest results that your assessor can read. Unclear retest terms are a common source of cost disputes after the first report is delivered.

Stop conditions and escalation

A well-run internal test defines in advance when the tester must halt, such as signs of production outage, data exposure beyond scope or discovery of an active intrusion unrelated to the test. Ask how the provider communicates these conditions, who receives the call at what hours, and how quickly the tester pauses. Confirm whether the provider will tell you about critical findings during the test rather than waiting for the report, and agree on a single emergency contact before testing begins.

Internal penetration testing cost, time and effort questions

What drives the cost of an internal penetration test?

The cost follows the written scope, so the main drivers are the number of network segments and sites, the size of the address space in scope, and whether the cardholder data environment and other critical systems are included. Starting access also matters: a test that begins with a standard user account needs different effort than one that begins with a network drop or no credentials. Segmentation testing adds work because each boundary must be checked from both sides. The engagement is a one-time cost, while retesting, scheduled repeat tests and any ongoing retainer recur. Ask the provider for a quote that lists the segments, the assumed starting access, the testing windows, the reporting deliverables and whether a retest round is included. DeployOpen does not publish a price list, and the quote follows the agreed scope.

How long does an internal network penetration test take?

Duration depends on scope size, the number of segments, the starting access level, how quickly that access is provisioned and how many rounds of client review the report needs. Planning comes first: NIST SP 800-115 places rules of engagement and management approval in a planning phase before discovery and attack begin, so time spent agreeing rules is part of the schedule. Testing windows may be set outside peak business hours to manage production risk, which can lengthen the calendar even when the hands-on effort is modest. Reporting and the debrief follow testing. The supplied sources do not give a fixed duration for this work, so ask the provider to set out each phase, its dependencies on your team and the calendar dates in the written plan before work starts.

Can our own team run an internal penetration test?

Yes, provided the tester meets the independence rule. PCI DSS requirements 11.4.2 and 11.4.3 accept a qualified internal resource or a qualified external third party with organizational independence, and neither needs to be a QSA or an ASV. Independence means the tester does not report into the group that builds, runs or is measured by the systems under test, so a team that administers a segment cannot grade its own controls. CIS Control 18 asks for an internal penetration test at least annually and allows clear box or opaque box approaches, which an internal team can also perform. Before relying on an internal team, confirm with your QSA how they will judge independence and qualification in your organization, and document the reporting line.

What does the client need to provide for internal network testing?

The work depends on several inputs from your side. Plan to provide:

Current network diagrams and segmentation documentation, including firewall rule sets for the cardholder data environment
An asset list with owners for systems in scope and a named contact for each segment
Signed rules of engagement that record management approval, stop conditions and testing windows
Provisioned starting access, such as a standard user account, a network drop or a jump host, agreed in advance
Coordination with the SOC and infrastructure teams on monitoring, backups and change freezes
An escalation path for any finding that could affect a production service

NIST SP 800-115 offers a rules of engagement template in Appendix B that can serve as the starting point for the written agreement. The more complete these inputs are at kickoff, the fewer scope changes you will pay for later.

Will a QSA accept an internal penetration test from a third party?

A QSA can accept an internal test performed by a qualified external third party with organizational independence, but the assessor decides whether the evidence meets the requirement in your environment. The test should cover the internal and segmentation work described in PCI DSS requirements 11.4.1 and 11.4.5 and include clear scope, methodology, findings, and evidence of retesting. Ask the provider to map the report sections to those requirements so your assessor can trace each claim. DeployOpen performs and documents testing and prepares evidence for compliance assessments, but it does not issue audit reports or attestations, and the assessor makes the acceptance decision. Confirm the expected evidence format with your QSA before the test starts.

How is retesting priced after an internal penetration test?

Retesting is priced by the work it requires, so it depends on how many findings need verification, whether any remediation changed the scope, and whether the retest repeats earlier attack paths or only checks specific fixes. Ask whether a retest round is included in the original quote or quoted separately, how long after the report it can be scheduled and what evidence the retest report will contain. Confirm whether findings marked as closed are verified by the tester or accepted on your statement. Keeping the retest in the same written scope avoids a second kickoff. Because the work is scoped in writing, you can compare the retest terms directly with the original engagement.

How often should internal penetration testing be repeated?

PCI DSS requirement 11.4.2 requires internal testing at least once every 12 months and after significant infrastructure or application changes. CIS Control 18 asks for an internal penetration test at least annually. Segmentation testing under PCI DSS requirement 11.4.5 follows the same 12-month and after-change rule, and service providers face a six-month cadence under requirement 11.4.6. Regulated organizations often add a test after a merger, a new data center, a cloud migration or a change to network segmentation, even when the calendar requirement has not yet come due. Agree the trigger list with your QSA or internal audit team so each change is assessed against the right requirement.

How DeployOpen scopes, tests, reports and retests internal networks

DeployOpen approaches internal network penetration testing as a fixed-scope engagement agreed in writing before any work starts. The method covers how access is provided, how segmentation and paths to critical systems are tested, how production risk is managed, and how findings are handed over and retested.

How we scope

Written scope names the network segments, address ranges, systems and cardholder data environment boundaries in play for the test.
Rules of engagement set the starting foothold, permitted techniques, testing windows and escalation contacts, agreed with management before testing.
Scope records whether testing is overt or covert and which IT staff know about the engagement and when.

How we build

Access is provided through an agreed foothold, such as a standard user account or a device placed on a named network, with its handling documented.
Testing follows the phases in NIST SP 800-115: planning, discovery, attack and reporting, with checkpoints agreed with your team.
Production risk is managed through agreed testing windows, throttled scanning, named contacts for each system and a defined stop procedure.

How we hand over

The report maps each finding to affected systems, the path used to reach them, and the steps needed to close that path.
Segmentation results state which controls were tested, what isolated the cardholder data environment and where isolation failed.
Evidence is retained so your team and any independent assessor can trace each finding to the test activity that produced it.

How we support

Retesting confirms that agreed fixes closed each path, and the retest scope is written before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer if your environment changes between formal tests.
Retest and remediation questions can be raised with the same team that ran the test, so context is not lost between engagements.