In-house vs third-party penetration testing

When in-house vs third-party penetration testing fits your organization

An internal team suits routine, well-scoped penetration tests where the independence rules for your framework are met. A third party suits regulator-driven, high-stakes or objectivity-sensitive work, such as threat-led testing under DORA or a red team exercise under TIBER-EU. If an audit or regulator deadline is on your calendar, start by asking which rule applies to that test, because the answer decides who may perform it before cost or convenience enters the discussion. Independence is a condition for compliance, not a preference. PCI SSC guidance allows qualified internal staff only if they are organizationally independent of the management of the target systems, and NIST SP 800-53 control CA-8(1) asks for testers free from perceived or actual conflicts of interest.

Many programs combine both. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and that principle applies to who does the testing as well. A common pattern is an internal team running frequent, scoped tests of its own applications and infrastructure, with an external firm running the annual or regulator-mandated test that the internal team cannot credibly perform. Confirm three things before you split the work: whether your framework names a minimum share of external testers, whether a third party that performed your compliance assessment is barred from also doing the test, and whether the internal team was involved in installing or maintaining the systems under test. Each answer can rule out an option that looked cheaper on paper.

How in-house and third-party penetration testing compare on each factor

This table compares in-house and third-party penetration testing across independence, cost, skills, evidence and regulatory constraints. Read each row for the condition under which one model's advantage matters, then check which regulator or framework applies to your organization before choosing.

Factor	In-house team	Third-party firm
Independence	Acceptable for PCI DSS only if testers are organizationally independent of the teams that manage the target systems. Matters most where the internal team does not run or build what it tests.	Independence is easier to demonstrate. Required in practice where a firm that installed, maintained or supported the target systems cannot also test them, and where DORA or TIBER-EU limit internal testers.
Regulator constraints	PCI DSS allows qualified internal staff. DORA threat-led testing requires prior approval for internal testers and external threat intelligence. TIBER-EU allows internal testers only in exceptional circumstances.	Required for DORA threat-led testing at significant credit institutions, and TIBER-EU strongly encourages external red team testers. Confirm with your competent authority whether your entity is in scope.
Objectivity	Testers know the environment and its history, which speeds analysis. Risk of blind spots and reluctance to report findings about colleagues' systems.	Fresh perspective on known weaknesses and assumptions. Matters most when the organization has run the same tests for years without an outside view.
Skills and tooling	Builds lasting internal capability and knowledge of your stack. Requires sustained training and tool licences. Matters where testing is frequent and the team can keep skills current.	Brings specialist depth across application, network and cloud testing and current tooling. Confirm named testers' qualifications and the methodology used, such as NIST SP 800-115, PTES or OWASP WSTG.
Scope control	Full control over timing, scope changes and production access. Useful where the organization needs to adjust tests quickly during live operations.	Scope, rules of engagement and deliverables are agreed in writing before work starts. Changes need a formal process, which adds control but can slow urgent retests.
Cost structure	Mostly recurring staff time, tools and training, with costs that stay even in quiet periods. Matters where tests run often enough to use the team fully.	Mostly per-engagement fees for a defined scope, with recurring cost only if you buy a retainer. Matters where tests are periodic or the required skills are rarely needed. Ask each vendor for itemized quotes.
Speed to start	Can start quickly once staff and tools are available. Delays come from competing priorities and gaps in skills.	Start depends on procurement, contracting and scheduling. Plan lead time for scope agreement and tester vetting, especially for regulated tests.
Evidence accepted by auditors	Acceptable where the tester meets independence and qualification rules. Assessors will ask for tester qualifications, methodology and independence evidence.	Often simpler for assessors to accept because independence and credentials are visible. Confirm the report content your assessor requires before engagement.
Cost of switching later	Moving to a firm later means handing over tooling knowledge and documentation. Matters if the team is small and key people leave.	Switching firms means new onboarding, a new scope and loss of prior context. Keep your own rules of engagement, asset lists and reports so the next provider can start faster.

What PCI DSS, NIST SP 800-53 and DORA require on tester independence

Independence is a condition for the test to count, not a preference. PCI SSC guidance allows a qualified internal team or a qualified third party to run the penetration test, provided the testers are organizationally independent of the people who manage the target systems. A third party that performs the entity's PCI DSS assessment cannot also run the penetration test if it installed, maintained or supported the systems in scope. Before you pick an internal or external model, map each target system to its owner and check whether the proposed tester reports into that same management line. Confirm the current wording with your assessor and the PCI SSC guidance itself, because assessors often read the independence point strictly.

NIST SP 800-53 Rev. 5 control CA-8, Penetration Testing, carries an enhancement for an independent team, CA-8(1), which asks that testers be free from perceived or actual conflicts of interest with the development, operation or management of the target systems. CA-8(1) is selected only in the high baseline in SP 800-53B Release 5.2.0, so confirm your system's baseline before you write it into your control set. If you are not in the high baseline, the enhancement may still be a useful benchmark for your own internal testing policy, but it does not bind you. Ask whether your independence rules cover people who built a feature, not only people who operate it.

DORA sets the strictest rules for threat-led penetration testing (TLPT), and only for entities their competent authority has identified for it. Under the TLPT rules, internal testers need prior approval, the threat intelligence provider must be external, and external testers must be used every third test. Significant credit institutions may use only external testers. Confirm with your competent authority whether your entity is in scope for TLPT and which tester model applies to it, and check the Commission Delegated Regulation on TLPT before you plan a rotation of internal and external work. Reserve internal capacity for the years between mandated external tests and budget for both.

What internal teams and outside firms each find and miss

Internal and outside testers see different parts of the same environment. The cards below tie each strength and blind spot to a specific condition, so you can judge which model fits your scope, your regulator and your evidence needs.

Internal knowledge speeds retests

An internal team already knows the asset inventory, the network layout and the change history, so it can reach the affected systems quickly after a fix. This matters most for retesting findings from an earlier round, where the goal is to confirm closure rather than rediscover the environment. Check whether your team has the authority, the tooling and the documented method to produce evidence an assessor will accept, and whether its tests are recorded in the same way each cycle.

Outside firms bring breadth

An external firm has tested many organizations and sectors, so it tends to try attack paths that an internal team has stopped considering. This is most valuable when you want an independent view of your highest-risk systems before a major release or a regulatory cycle. Ask for named testers, their prior experience with your technology stack, and whether they will report on attack chains as well as individual findings.

Familiarity bias hides weaknesses

Testers who built or run a system tend to accept its design assumptions, so they may miss flaws that an outsider questions immediately. The risk grows when the same team configures, operates and tests the same platform. Mitigate this by rotating test scope, having a reviewer outside the operating team check the test plan, and recording which assumptions each test accepted.

Outside access and time are limited

An external firm works within the access, accounts and time window written into its engagement. It may not see internal trust relationships, legacy systems or third-party integrations unless the scope includes them. Before signing, confirm which credentials and network positions the testers receive, how out-of-scope systems are handled, and what happens if they find a path that leaves the agreed boundary.

Manual exploitation is required

PCI SSC penetration testing guidance describes the work as essentially manual and says running an automated tool alone does not satisfy the requirement. Whichever team you use, confirm that a qualified tester performs the exploitation and chains weaknesses, and that the report shows the manual steps taken. This check applies to internal and external teams alike, so ask for a sample report before you commit.

Both teams validate detections

CIS Safeguard 18.4 asks that security measures be validated after each test so that detections cover the techniques testers used. An internal team can confirm alerts quickly, while an outside team can show which attacks went unnoticed. Plan for both to share the test log and timestamps so the security operations team can map each step to a detection or a gap.

What you receive from an internal team versus an outside firm

This table compares what each option typically hands over: report content, rules of engagement, methodology references, retest evidence, independence attestation and what assessors ask for. Exact deliverables are set in the written scope, so read each cell as a question to put to your internal team or to a provider before signing.

Deliverable	Internal team	Outside firm
Rules of engagement	Usually drafted and approved internally, so the scope, testing windows and escalation contacts must be written down and signed by management	Normally agreed in writing before work starts, often using a rules of engagement template such as the one in NIST SP 800-115 Appendix B
Methodology reference	Ask which framework the team follows, such as NIST SP 800-115, PTES or OWASP WSTG, and whether it is documented	Ask the firm to name the methodology in the report and map its steps to the chosen framework
Report content	Depends on the internal template; confirm it covers scope, exploitation evidence, risk rating and remediation steps	Commonly includes an executive summary, technical findings, proof of exploitation and remediation guidance; confirm the exact contents in the scope
Independence attestation	Internal testers are not independent of the teams that run the systems, so a written statement of organizational independence from management may be needed	A written statement that the firm did not install, maintain or support the target systems, where the assessor requires one
Retest evidence	Often informal; ask for a dated record showing each finding was re-exercised and closed	Frequently a separate retest is priced in the scope; confirm whether it is included and what proof is delivered
Evidence an assessor expects	Records of who tested, when, what was in scope and what was fixed, backed by an independence statement	Signed report, named tester qualifications, scope statement and independence confirmation tied to the test period
Scope and deliverables	Set by internal planning and recorded in the test plan	Set in the written scope agreed before work begins; confirm every deliverable listed here against that document

Which approach to choose by regulatory and organizational situation

Financial entities identified by their competent authority for threat-led penetration testing operate under Article 26 of DORA, which requires this testing at least every three years. The Commission Delegated Regulation (EU) 2025/1190 sets out the technical standards for these tests, and the TLPT framework limits how internal staff can take part. Under that framework, internal testers need prior approval, the threat intelligence provider must be external, and external testers must be used every three tests. Significant credit institutions may use only external testers. Your internal team can still run the wider Article 25 programme (vulnerability scans, open source analysis, scenario-based tests and standard penetration tests) in between.

External threat intelligence: The provider supplying threat intelligence for the test must come from outside your organization.
Tester rotation: Count your past threat-led tests so you know when the every-third-test external requirement applies.
Significant institution status: If your competent authority classifies you as significant, plan for external testers only.
Internal role: Internal staff typically coordinate, support and approve, and can be placed on the team only with prior approval.
Interval planning: Schedule the threat-led cycle against the three-year maximum and the lead time for procurement.

Confirm with your competent authority whether you are in scope, your significance status, and how the every-third-test rule applies to your history.

What drives the cost and effort of each approach

Both models spend money on people, tools and retesting, but they pay different people for different work and recur at different points. The cards below show which cost components sit on each side, what moves them, and what to ask for before comparing quotes or headcount plans.

Internal staff time and salaries

An internal team is paid through salaries, recruitment and the time testers spend away from other security work. Hiring is a one-time cost, while salaries, training and retention recur every year whether or not a test runs that quarter. Costs rise when the team must cover many applications, cloud accounts and roles, and fall when testing is steady and well scheduled. Ask how many testers are needed to cover your scope and how much of their year goes to testing versus operations.

External fees set by written scope

A third-party firm bills against the scope, deliverables and timeline agreed in writing before work starts. The main drivers are the number of targets, the depth of authenticated access, whether the work runs in production or staging, and how many report cycles are included. Fees are generally one-time per engagement and recur only when you buy another test. Ask each vendor to state the targets, roles, environments and retest terms in the quote so bids can be compared on the same basis.

Tooling and licenses

Internal teams must buy, maintain and renew their testing tools, including proxies, scanners, exploitation frameworks and reporting software. Licenses usually recur annually, and some commercial tools price by target count or user seat. A third-party firm typically brings its own tooling into the engagement, so you pay for that within the fee rather than as a separate license. Confirm which tool licenses your team would need to keep current and whether the vendor's quote includes its tooling.

Lab environment build

PCI SSC guidance suggests a development lab where penetration tests can run outside production, and internal staff can build experience there. Building that lab is a one-time cost in hardware or cloud capacity, configuration and test data, and it recurs as systems change and the lab must mirror production. Without a lab, an in-house team tests either on live systems or on staging copies that may not match. Ask how closely the lab matches production and who keeps it current.

Retest cycles and skills maintenance

Each fix needs validation, and that retest work recurs after every test cycle, so the cost is shaped by remediation volume as much as by test frequency. Internal teams also spend time keeping skills current as applications, cloud services and attack techniques change. External firms carry this cost in their staffing but may charge separately for retests. Ask whether retests are included, how many are covered, and what the vendor does to keep testers current on your stack.

Regulator-mandated external engagements

Some frameworks require external testers regardless of an internal team's capability. Under DORA, threat-led penetration testing for significant credit institutions may use only external testers, and TIBER-EU requires an external threat intelligence provider. Outside firms in these cases are a recurring cost tied to the regulatory cycle, and an internal team cannot substitute for them. Confirm with your competent authority or regulator which engagements apply to you before budgeting for internal staff alone.

How to combine internal and external testing without losing independence

The most defensible split keeps routine work in-house and reserves independent testing for the tests that a standard or regulator says must be independent. Internal staff can run vulnerability scans, retests after fixes and exploratory checks, and PCI SSC's penetration testing guidance suggests a development lab where those staff can practice outside production and build experience. The independent firm then takes the scheduled penetration test and any test a regulator requires to be external, so its results carry the weight an auditor or supervisor will look for.

Scope and evidence must stay consistent across both groups or the results cannot be compared. Keep one asset inventory, one rules of engagement document modeled on the template in NIST SP 800-115, and one finding register that records the same severity scale and identifiers whoever found the issue. Agree in writing which systems each party tests, which accounts they use and how retests are closed out. Ask any external firm to state in its proposal whether it will reuse your methodology or bring its own, and confirm that its report format can be mapped to your register.

Do not confuse scans with penetration tests. PCI DSS treats internal vulnerability scanning and penetration testing as separate requirements, and a scan run by a qualified internal team does not satisfy the penetration testing requirement, which PCI SSC describes as essentially manual. Check the independence rule for each one before you assign it: the internal scanner should be reasonably independent of the components it scans, and an internal penetration tester must be organizationally independent of the systems' management. Confirm both conditions with your qualified security assessor before the first test cycle, not after the report is delivered.

How much effort, time and skill does in-house testing really need?

Can an internal team alone satisfy PCI DSS or DORA penetration testing requirements?

Sometimes, but only under conditions. PCI SSC guidance allows qualified internal resources to perform the penetration test if they are organizationally independent of the management of the target systems. For DORA threat-led penetration testing, internal testers need prior approval, the threat intelligence provider must be external, external testers must be used every three tests, and significant credit institutions may use only external testers. Confirm with your assessor and competent authority which conditions apply to your entity before you staff the work internally. Also remember that simply running an automated tool does not satisfy PCI SSC's penetration testing expectations, so the internal team needs manual exploitation skills.

What does an outside penetration test cost, and what drives the price?

No supplied source gives a price for penetration testing, so ask providers for figures against a written scope. Most of the cost is tester time, which scales with the number of applications, network segments, user roles and environments in scope, plus the depth of exploitation and the reporting and retest work. Cost components to separate in a quote include the scoping and rules of engagement, the testing days, the report, any retest, and any travel or after-hours work. One-time costs are the first engagement and remediation of findings. Recurring costs come from annual or more frequent tests and any retainer. An internal team carries comparable costs in salaried time, tooling, training and the time taken away from other work, which is usually harder to see on a budget line.

How long do procurement and scoping take before a penetration test starts?

No supplied source gives a duration, so confirm the timeline with each provider in writing. The time is usually spent on defining targets, agreeing rules of engagement, provisioning test accounts, arranging access and change windows, and signing the contract. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, so a clear asset inventory shortens this phase. Procurement for an outside firm adds vendor onboarding and security review of the provider. An internal team avoids that step but still needs its own scoping and approval cycle, and it may need to demonstrate independence from the systems it tests.

What do internal staff need to provide during an engagement?

Whichever party tests, the work needs access and coordination from your own staff. Typical needs are:

Network access paths and an agreed source IP range for the testers
Test accounts for each application role, with safe provisioning and removal
Named contacts for escalation if a test disrupts a service
Change windows for any production testing, and a rollback plan
Architecture diagrams, asset lists and a current segmentation view

NIST SP 800-115 describes a rules of engagement document as the place to record these arrangements, and it provides a template in Appendix B. Ask a provider how they handle credentials and whether they need your monitoring team to be told in advance.

Can an internal team be trained to a recognized penetration testing standard?

Yes, a team can be trained against published methods, although the supplied sources do not give training durations or costs. The PCI SSC guidance suggests organizations consider a development lab where penetration tests can run outside production, which lets internal staff build experience safely. The OWASP Web Security Testing Guide and PTES both give a structured method to follow, and NIST SP 800-115 does not endorse one methodology over another. Ask any training provider which methods the course covers, how practical exercises are assessed, and whether the course is recognized by the scheme your assessor or regulator uses.

How does CREST accreditation affect the choice of an outside provider?

CREST is a UK not-for-profit company that accredits member companies and certifies individuals in disciplines including security testing and red teaming. Its accreditation tells you that the company meets CREST's standards, and its individual certifications show that named testers have passed CREST exams. The Bank of England names CREST as the accreditation and certification body for CBEST, so a UK financial institution running CBEST should check this directly. Procurement teams often ask for CREST status, but it does not replace checking the tester's experience against your systems, and some other schemes or regulators may ask for different credentials. Confirm the requirement with your regulator or assessor first.

Should an internal team test its own systems, or should an outside firm do it?

The independence rules decide much of this. PCI SSC and NIST SP 800-53 CA-8(1) both expect testers to be free from conflicts with the management of the target systems, and a third party that installed or supports the target systems cannot also perform the PCI DSS assessment. An internal team that administers a system is therefore unlikely to be the right tester for that system, even if it has the skill. Internal teams suit frequent, targeted checks and learning, while outside firms often add objectivity and evidence that auditors accept more readily. Many organizations combine both, as NIST SP 800-115 notes that techniques are often combined to reach an acceptable level of risk.

What to put in the written scope before you hire or assign testers

This sequence turns an informal request for a penetration test into a written scope that an internal team, an outside firm and an auditor can all read the same way. Each step ends with a document or check that you can point to later.

Confirm the mandate and the baseline
Start by recording why the test is being run, which obligation it serves (for example, a PCI DSS requirement, a NIST SP 800-53 control such as CA-8, or a DORA testing obligation) and which systems are in the target set. Pull the current asset inventory, network diagrams, data flows and any earlier test reports so the scope starts from what is actually deployed rather than from memory. The owner of the mandate signs the baseline. You know it is done when every in-scope system has an owner, an environment label (production, staging or development) and a reference to the last test that covered it.
Document tester independence
Write down who will test, which team they belong to and who manages the systems under test. Compare that against the independence conditions in the standard or regulation that applies, such as the PCI SSC guidance on organizational independence or the independence wording in NIST SP 800-53 guidance for CA-8(1). If any internal tester installed, maintains or supports a target system, record that conflict and either reassign the work or document why the rule allows it. Ask any outside firm to confirm in writing that it has not supported the same systems. The file is complete when each tester is named with a reporting line and a signed independence statement is on record.
Agree rules of engagement
Use the rules of engagement template in Appendix B of NIST SP 800-115 as the starting structure. Cover permitted techniques, forbidden actions (for example, denial of service or data destruction), testing windows, source addresses, points of contact, escalation paths for critical findings and what happens if a tester gains access to sensitive data. Have legal, the system owners and the test lead sign the document. It is done when every technique the testers may use appears in the document and the people who can stop a test are named with a way to reach them.
Set deliverables and retest terms
Specify the report contents, including scope, methods, exploited findings with evidence, risk ratings, and remediation guidance mapped to each finding. Decide whether the report is delivered to the security team only or also to the executive sponsor. Define how retests are scheduled and who verifies closure. For an outside firm, check that these items appear in the statement of work and the fixed scope. The step closes when a written deliverables list has been agreed and the retest process names a verifier independent of the remediation team.
Plan evidence for auditors
List the records an auditor or regulator will ask for: the signed scope, independence statements, rules of engagement, tester qualifications, raw evidence handling rules, the final report and remediation tracking. Decide where these records are stored and who can read them. Confirm with the relevant auditor or competent authority which format they accept, since the evidence an assessor needs can differ between a PCI assessment, a NIST-based assessment and a DORA supervisory review. The step is complete when an evidence checklist exists, each item has an owner and the auditor's acceptance format is confirmed in writing.
Confirm the quote matches the written scope
Before signing, compare the quote or internal effort estimate line by line against the scope document. Ask what drives the cost: number of targets, application roles, environments, retests and report depth are typical drivers. Ask which costs are one-time, such as the initial test, and which recur, such as annual retests. For an outside firm, confirm that out-of-scope work is priced as a change request. The check passes when every scope item maps to a quoted line and nothing in the quote is undefined.

Why threat-led testing rules shift the answer for regulated banks

For a bank in scope of threat-led testing, the in-house or third-party question is often settled by the rules before cost or skills come into it. Under TIBER-EU, the test needs an external threat intelligence provider, external red team testers are strongly encouraged, and internal testers are allowed only in exceptional circumstances, with the test manager's prior approval and to the same standards. DORA's threat-led penetration testing rules follow a similar pattern: internal testers need prior approval, the threat intelligence provider must be external, external testers must be used every three tests, and significant credit institutions may use only external testers. Read the exact conditions in the TIBER-EU Framework (January 2025) and the DORA text, and confirm with your competent authority which regime applies to you.

A threat-led test also produces a different kind of result than a standard penetration test. The ECB states that TIBER-EU tests produce no pass or fail result, so a clean outcome does not certify the bank's defenses and a finding does not fail an exercise. Your evidence instead centers on what the testers attempted, what your detection and response teams saw, and what you changed afterward. Ask your competent authority whether they expect a specific report structure, and ask any proposed provider how their reporting maps to the closure phase of the framework.

Before you commit budget to an internal team for threat-led work, check three things with the regulator and your procurement function: whether your entity is in the group expected to run threat-led tests, whether an internal tester would be approved for the scope, and whether your chosen external provider can meet the procurement guidance for service providers. Internal teams still have a role in the preparation and remediation work around these tests, and that split should be written into the engagement plan before testing begins.

How DeployOpen scopes, delivers and supports security testing

DeployOpen works as an outside firm that plans, runs and documents security testing inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For teams weighing in-house testing against an external provider, we help define the written scope, the independence requirements and the evidence an auditor will expect.

How we scope

Engagements are fixed-scope, with targets, deliverables and timelines agreed in writing before work starts.
The written scope states which viewpoint is tested, internal or external, and which access level testers begin with.
We confirm whether the applicable framework requires an organizationally independent tester, and record how that is met.
Rules of engagement cover production or staging targets, testing windows and who approves any change in scope.

How we build

Testing is planned around the written scope, with manual exploitation supported by tooling rather than replaced by it.
Where a client keeps an internal team, we can define how that team's work is reviewed and what standard it must meet.
Test environments are configured to match the agreed production or staging target, with differences recorded in the report.
Findings are validated by the tester before they are written up, so each item in the report can be reproduced.

How we hand over

Reports document scope, methods, access used, findings, evidence and remediation steps for each target in the engagement.
Written deliverables are structured so an internal team or an external auditor can trace each finding to its test.
We walk the client team through findings and agree which items need retesting once fixes are in place.
Testers' independence statements and engagement records are kept with the report for later audit requests.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope engagement.
A retainer can cover scheduled retests, updated test plans after major changes and questions from auditors.
Clients who build internal capability can ask for knowledge transfer alongside each engagement, agreed in the written scope.
Before signing, ask for the scope, deliverables, retest terms and independence statement, and confirm each in writing.