Penetration Testing Services for Enterprise and Government

Penetration testing services put a qualified attacker against your systems under contract, on a fixed scope, and hand you a report you can act on. Sthenos runs penetration testing services, vulnerability assessment services, and IT security audit engagements for enterprise and government teams across network, web, API, cloud, and application layers, following NIST SP 800-115 and the OWASP Testing Guide. Every engagement ends with a retest, because a finding you have not re-verified is still an open finding.

What penetration testing services cover

A penetration test is scoped by attack surface, not by product name. Most engagements combine two or three of the areas below. Naming the surfaces up front is what keeps the quote honest and the results comparable between vendors.

Penetration testing types, and which one your situation calls for

Buyers rarely need “a penetration test”. They need a named type, against a named surface, for a named reason. The catalog below defines the types that exist, what each one covers and what each one leaves untested, so you can write the scope line yourself before anyone quotes you. The surfaces Sthenos tests are the ones set out under what penetration testing services cover above; anything outside them is settled in scoping before a quote is issued.

External network penetration testing

What it covers. The internet-facing perimeter: exposed hosts and services, remote access edges including VPN, and the forgotten subdomains that never made it onto the asset inventory. The PCI Security Standards Council describes the scope of an external test as the exposed external perimeter and the critical systems connected or accessible to public network infrastructure, and requires both application-layer and network-layer assessment. What it does not cover. It says nothing about what someone already inside your network can reach.

Internal network penetration testing

What it covers. What an attacker does after the first foothold: lateral movement, privilege escalation, credential reuse, and whether network segmentation actually holds. The PCI Security Standards Council frames the internal test as testing the internal perimeter and critical systems from the perspective of the internal network. What it does not cover. It assumes the foothold rather than earning it. How that foothold is obtained is answered by the external test or by a phishing simulation.

Web application penetration testing

What it covers. Authentication, session handling, access control between users and between roles, business logic abuse, and injection. The reference work is the OWASP Web Security Testing Guide, which OWASP describes as producing the premier cybersecurity testing resource for web application developers and security professionals, currently at version 4.2. What it does not cover. The host operating system underneath, the network around it, and the identity configuration of the cloud account it runs in are all separate scopes.

API penetration testing

What it covers. REST and GraphQL endpoints tested for object-level and function-level authorisation, data the interface hides but the API returns, and rate limiting. The PCI Security Standards Council added guidance on back-end APIs to its penetration testing supplement precisely because an API behind a tested front end is routinely left out of scope. What it does not cover. It does not exercise the browser or mobile client in front of the API, where session handling and client-side controls live.

Mobile application penetration testing

What it covers. The application on the device and the traffic it generates: local storage of tokens and personal data, transport and certificate handling, platform interaction, and resilience against tampering. OWASP publishes a dedicated project for this, providing a security standard for mobile apps in the MASVS, a list of mobile-specific weaknesses in the MASWE, and a testing guide in the MASTG. What it does not cover. The server behind the app. Most mobile findings that carry real impact are API findings, so scope both or scope the API.

Cloud configuration and identity testing

What it covers. Identity and role bindings, storage exposure across buckets, blobs, snapshots and backups, network boundaries, and infrastructure-as-code drift across AWS, Azure and Google Cloud. What it does not cover. A configuration review is not an exploitation test of the workloads running inside the account, and cloud providers set their own rules for what may be tested, which is why notification is handled during scoping rather than discovered mid-test.

Wireless penetration testing

What it covers. The radio boundary: authentication on corporate and guest networks, rogue and look-alike access points, and whether a wireless client can reach the wired network it should be segmented from. What it does not cover. It stops at the point of association. What an attacker does once on the network is an internal network test. This type is not described on this page as a Sthenos service; ask us in scoping.

Social engineering and phishing simulation

What it covers. Whether a person can be induced to hand over a credential or run something. The PCI Security Standards Council defines social engineering as the manipulation or deception of individuals into divulging confidential or personal information. NIST SP 800-53 names social engineering attacks as interactions by email, telephone, shoulder surfing or personal conversation. What it does not cover. A campaign measures a moment, not a control, and the number it produces moves with the pretext used. It is run only with written authorisation, as stated in the scope figure above.

Physical penetration testing

What it covers. Attempts to bypass or circumvent the controls on physical access points to a facility, announced or unannounced. That is the wording of NIST SP 800-53 control enhancement CA-8(3). What it does not cover. It is explicitly outside the scope of NIST SP 800-115, which places physical security testing and other non-technical means of attack outside that publication. This type is not described on this page as a Sthenos service; ask us in scoping.

Red team, and what people mean by purple team

What a red team covers. The NIST glossary, sourcing CNSSI 4009-2022, defines a Red Team as a group authorised and organised to emulate a potential adversary’s attack or exploitation capabilities against an enterprise’s security posture, with the objective of demonstrating the impact of successful attacks and what works for the defenders, who are the Blue Team. NIST SP 800-53 adds that red team exercises extend the objectives of penetration testing by examining the capability to implement effective cyber defences. It is objective-based, multi-surface, and usually unannounced to the defenders. What it does not cover. Coverage. A red team that reaches its objective by one path leaves every other path untested, which is why it is a poor substitute for a scoped test when a framework asks for evidence.

Vulnerability assessment vs penetration testing

These get quoted against each other constantly, and they answer different questions. A vulnerability assessment tells you what is exposed. A penetration test tells you what an attacker can actually do with it. Buying the wrong one is the most common waste in this category.

Scan, assessment, test, red team: four things that get quoted against each other

Four different products are sold under the word “testing”, and a proposal for one is routinely compared against a proposal for another. The table below separates them by the question each one answers, so you can tell which of them a requirement is actually asking for before you compare prices.

Black box, grey box and white box

The second half of a scope line is how much the tester is told before they start. These three words are defined by the PCI Security Standards Council in its penetration testing guidance, and they change the price, the duration and the depth of what you get back.

What drives the price of a penetration test

Read this before the price table below, because it explains the numbers rather than asking you to accept them. Seven things move the figure on a penetration testing quote. None of them is the vendor’s size, and any proposal that cannot show you which of these it assumed is not comparable to one that can.

1. The type of test. An external network test, a web application test and a red team exercise are three different products with three different cost bases. Naming the type is the first line of the scope, and it is a line quotes leave vague.
2. The approach. Black box, grey box or white box, as defined above. The PCI Security Standards Council notes that a black box assessment, where no details of the target are provided in advance, may require more time, money and resources for the deliverables to meet the requirements of PCI DSS.
3. The count of targets. This is the number that actually multiplies: distinct applications, user roles to be tested against each other, API endpoints, internal subnets, public IP addresses, and employees in a phishing scope. Ask any vendor which counts their price assumed, and what happens when the real count differs.
4. Whether a retest is included. A quote with the retest inside it and a quote with the retest billed afterwards are not the same quote. Sthenos includes the retest, which is why our figures below are compared like for like against the market.
5. Report depth. A technical findings report alone costs less than a technical report plus an executive summary written for a board, plus a remediation working session with your engineers. Decide who has to read the output before you price it.
6. Tester seniority and independence. Business logic flaws are found by people, and people are the cost. Where independence matters, NIST SP 800-53 control enhancement CA-8(1) is the clause that names it: an independent penetration testing agent or team, free from perceived or actual conflicts of interest with the development, operation or management of the target system.
7. Constraints on when testing may run. Change freezes, out-of-hours windows, provider notification for certain cloud test types, and a production environment that cannot absorb load all add elapsed time, and elapsed time is priced.

How much does penetration testing cost?

Penetration testing cost is driven by scope size and testing depth, not by vendor size. Below is what the market charges, compiled from third-party industry sources, and what we charge for the same scope. Our figures include the retest.

Three things move the number more than anything else: how many distinct applications or subnets are in scope, whether testing is black box or credentialed, and whether the engagement includes a retest. We quote all three explicitly rather than as a single line item.

Our penetration testing methodology

Every engagement runs the same five phases, whether it is a single API or a full internal network. The phases come from NIST SP 800-115 and the Penetration Testing Execution Standard, so the output is comparable against any other competent firm’s work.

The methodologies and standards a penetration test is measured against

A methodology is what makes one firm’s report comparable to another’s. Without one, a findings list is an opinion. The nine references below are the ones a penetration test is measured against, and every description here is taken from the body that issues it, with a link so you can read the source rather than take our summary of it. Four of them already appear at the top of this page as the standards our engagements are executed against.

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment

Issuer: NIST. Its stated purpose is to assist organizations in planning and conducting technical information security tests and examinations, analyzing findings, and developing mitigation strategies, with an emphasis on specific technical techniques, the benefits and limitations of each, and recommendations for their use. It names four phases of a penetration test, planning, discovery, attack and reporting, with a loop from the attack phase back into additional discovery, and it states that the reporting phase runs simultaneously with the other three rather than only at the end. NIST SP 800-115.

OWASP Web Security Testing Guide

Issuer: OWASP. OWASP describes the project as producing the premier cybersecurity testing resource for web application developers and security professionals, currently at version 4.2. Its practical value in a report is the identifier scheme: every test scenario carries an identifier in the form WSTG followed by a four character category and a number, so a finding can cite the exact scenario it came from and a second firm can repeat it. OWASP Web Security Testing Guide.

OWASP Application Security Verification Standard

Issuer: OWASP. OWASP states that the ASVS provides a basis for testing web application technical security controls and also provides developers with a list of requirements for secure development. Where the Testing Guide says how to test, the ASVS says what a control has to achieve, which is what makes it the useful half when a test result has to become a fix. OWASP ASVS.

OWASP Top 10

Issuer: OWASP. OWASP describes it as a standard awareness document for developers and web application security that represents a broad consensus about the most critical security risks to web applications. It is an awareness document by its own definition, so treat a proposal that offers only the Top 10 as a scope floor rather than a methodology. OWASP Top 10.

OWASP Mobile Application Security

Issuer: OWASP. The project provides a security standard for mobile apps in the MASVS, a list of security and privacy weaknesses specific to mobile apps in the MASWE, and a testing guide in the MASTG covering the processes, techniques, tools and test cases that let testers deliver consistent and complete results. OWASP Mobile Application Security.

PTES, the Penetration Testing Execution Standard

Issuer: the PTES project. The standard states that it consists of seven main sections, and names them: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation, and reporting. Its own text says it does not provide technical guidelines for how to execute a test, which is what a separate technical guideline covers. Its value on a proposal is that the seven sections are a checklist a buyer can hold the vendor to. PTES.

MITRE ATT&CK

Issuer: MITRE. MITRE describes ATT&CK as a globally accessible knowledge base of adversary tactics and techniques based on real-world observations, used as a foundation for developing threat models and methodologies in the private sector, in government, and in the security product and service community. Findings mapped to ATT&CK techniques let a defender check whether existing detections would have caught the step, which turns a test report into a detection backlog. MITRE ATT&CK.

CVSS v4.0, the Common Vulnerability Scoring System

Issuer: FIRST. FIRST describes CVSS as an open framework for communicating the characteristics and severity of software vulnerabilities, consisting of four metric groups: Base, Threat, Environmental and Supplemental. Base metric values combine with default values that assume the highest severity for Threat and Environmental to produce a score from 0 to 10, and Threat and Environmental metrics are then amended against real threat intelligence and the actual environment. The published qualitative scale is None at 0.0, Low at 0.1 to 3.9, Medium at 4.0 to 6.9, High at 7.0 to 8.9 and Critical at 9.0 to 10.0, and FIRST states that using these ratings is optional. Ask for the vector string, not the adjective: the vector is what lets you re-score a finding for your own environment. CVSS v4.0 specification.

CWE, the Common Weakness Enumeration

Issuer: MITRE. MITRE describes CWE as a community-developed list of common software and hardware weaknesses, where a weakness is a condition in a software, firmware, hardware or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities. A finding tagged with a CWE tells your engineers what class of defect to look for elsewhere in the codebase, which is the difference between fixing one bug and closing a pattern. About CWE.

PCI DSS penetration testing, Requirement 11

Issuer: PCI Security Standards Council. The council publishes an information supplement, Penetration Testing Guidance, version 1.1 dated September 2017, written by its Penetration Test Guidance Special Interest Group. That document sets out the scope of external and internal testing, segmentation testing, the three testing approaches, and the difference between a scan and a test, and it states that penetration testing must be performed at least annually and after any significant change. It also states plainly that it provides supplemental information and does not replace or supersede requirements in any PCI SSC standard, and that requirement numbering should be read against the current version of PCI DSS. Read the standard itself for the binding text. PCI DSS at the PCI Security Standards Council.

How an engagement runs, and what we need from you at each step

The phases above describe what Sthenos does. This section describes what you do, because a common cause of a slipped penetration test is a client input that nobody named at kickoff. NIST SP 800-53 states that all parties agree the rules of engagement before penetration testing scenarios commence, and everything below hangs off that document.

What lands on your desk

A penetration test is bought as an activity and consumed as a set of documents. These are the artefacts a competent engagement produces, and the ones you should ask any vendor to itemise in the proposal rather than describe as “a report”.

• The scope agreement and the rules of engagement
• The technical findings report
• The executive summary
• The test protocol
• The remediation plan
• The retest report

1. The scope agreement and the rules of engagement. Signed before anything is touched. It names the assets, the approach, the windows, the prohibited techniques, the escalation path and the stop condition. This is a deliverable, not paperwork: it is the document that tells a later auditor what was and was not covered.
2. The technical findings report. Each finding with a severity, the evidence, and reproduction steps a developer can follow without the tester in the room. The PCI Security Standards Council describes a penetration test report as giving a description of each vulnerability verified or potential issue discovered, and the specific methods by which and extent to which it may be exploited. Ask for CVSS vectors rather than adjectives, and for CWE identifiers where a finding is a class of defect rather than a one-off.
3. The executive summary. The same test written for a reader who will not open the technical report: what an attacker could achieve, what it would cost the business, and what has to be decided. This is the document that travels to a board, an insurer or a customer.
4. The test protocol. What was tested, by which approach, in which stages, with which methods and tools. Ask for it by name: without it a reader cannot tell a two-week human-led engagement from a scanner run, and neither can an auditor.
5. The remediation plan. Findings sequenced by risk against effort, with an owner suggested for each, so the report becomes a backlog rather than a PDF. Sthenos runs this as a working session with your engineers rather than sending it.
6. The retest report. Every confirmed finding re-tested after your fix, with the status updated in a reissued report. That reissued document, not the original, is the one a customer or auditor actually wants to see, because it shows the findings closed.

Cyber security assessment and IT security audit services

Not every question needs an attacker. Cyber security assessment services and IT security audit services evaluate your controls, policy and architecture against a named framework, and are usually what a board, insurer or prime contractor is actually asking for when they say they want a security review.

• Information security audit services and cyber security audit services measured against ISO/IEC 27001 Annex A or the NIST Cybersecurity Framework, producing a control-by-control gap register.
• Cyber security compliance services mapping your current state to the framework your contract names, whether that is SOC 2 criteria, HIPAA, PCI DSS, CMMC or FedRAMP.
• Architecture and configuration review against CIS Benchmarks for the platforms you actually run, rather than a generic checklist.
• Identity and access review covering privileged accounts, service principals, joiner-mover-leaver handling and standing access that should have expired.

Application security and cloud security services

Application security services move testing left, into the build, so the annual penetration test stops finding the same class of defect every year. Cloud security services address the configuration layer, which is where most cloud incidents actually begin.

Application security

• Secure code review on the paths that handle authentication, authorisation and money.
• Threat modelling at design time for new services, using STRIDE or attack trees.
• SAST and dependency scanning wired into CI so a vulnerable package fails the build.
• Developer remediation sessions, so fixes hold rather than recur next release.

Cloud security

• AWS, Azure and Google Cloud configuration review against CIS Benchmarks.
• Identity and role analysis, targeting over-broad permissions and unused standing access.
• Storage exposure review across buckets, blobs, snapshots and backups.
• Infrastructure-as-code policy checks, so a corrected setting cannot be reintroduced by the next deploy.

Cybersecurity consulting services

Testing tells you where you stand. Cybersecurity consulting services decide what to do about it. Our cyber security consulting work is advisory rather than tool-led: we help you sequence remediation against risk and budget, and we do not resell the products we recommend.

• Fractional security leadership. A named advisor acting as vCISO for organisations that need the judgement without a full-time hire.
• Security programme design. Building the policy set, risk register and control map from nothing, or rebuilding one that has drifted.
• Remediation roadmaps. Turning a findings report into a sequenced plan with owners, effort estimates and dependencies.
• Third-party and vendor risk. Assessing the suppliers inside your boundary, which is where an increasing share of incidents originate.
• Incident readiness. Tabletop exercises and runbook review, so the first time you practise is not during an actual breach.

Organisations approach this under several names. IT security consulting, information security consulting and cyber security consultancy all describe the same engagement shape here: a senior practitioner, a defined question, and a written answer you own.

Security testing in the software development lifecycle

Security testing belongs inside delivery, not only at the annual audit. Where conventional software testing asks whether the system does what it should, security testing services ask what else it can be made to do. Teams that treat software testing and security testing as one discipline find defects while they are still cheap to fix.

• Requirements and design. Abuse cases written alongside user stories; threat modelling before the first commit.
• Build. SAST and software composition analysis gated in CI, so a known-vulnerable dependency fails the pipeline.
• Pre-release. Targeted DAST and manual testing on authentication, authorisation and payment paths.
• Production. Continuous vulnerability assessment services plus an annual penetration test for proof.

What a penetration test satisfies

Most organisations buy a test because a framework, a customer or an insurer asked for one. Here is what each commonly expects, so you can scope once and satisfy the requirement rather than testing twice.

Which frameworks ask for a test, how often, and what the words actually say

The table above summarises what each requirement commonly expects. This section gives you the underlying text and a link to the issuer, because the gap between what a framework says and what a vendor says it says is where budget gets wasted. Two of the entries below are the ones people get wrong. The full catalog of seventeen frameworks, each with its issuer and who it binds, sits on our cybersecurity services page.

PCI DSS: a test is required, and a cadence is stated

PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment, which the council states includes merchants, processors, acquirers, issuers and service providers. Its penetration testing guidance states that penetration testing must be performed at least annually and after any significant change, for example an infrastructure or application upgrade or a new system component installation, and that what counts as significant is not prescribed by PCI DSS but is decided by the entity’s own risk assessment. Segmentation controls have their own testing requirement where segmentation is claimed. Scope covers the external perimeter and the internal perimeter, at application layer and network layer. Sources: PCI DSS at the PCI Security Standards Council and its Penetration Testing Guidance information supplement, version 1.1, September 2017. Requirement numbering has changed between PCI DSS versions, so read the current standard for the binding clause.

HIPAA: an evaluation is required, and penetration testing is not named

This is one buyers get wrong. The HIPAA Security Rule at 45 CFR 164.308(a)(8) sets a standard called Evaluation: perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under the rule and subsequently in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity’s or business associate’s security policies and procedures meet the requirements of the subpart. It does not name penetration testing, and there is no HIPAA certification. A test is one way to evidence the technical half of that evaluation, which is why auditors ask for one and why the requirement is written as periodic rather than annual. Source: 45 CFR 164.308. See also our explainer on HIPAA compliant software.

SOC 2: an attestation by a CPA, not a testing mandate

The AICPA describes System and Organization Controls as a suite of service offerings CPAs may provide in connection with system-level controls of a service organization or entity-level controls of other organizations. SOC 2 is therefore an attestation performed by an accountant against criteria, not a technical standard that mandates a penetration test. Auditors commonly ask for one as evidence of a vulnerability management programme, and customers commonly ask for one alongside the report, which is why an annual test is the practical norm rather than a stated rule. Source: AICPA, SOC suite of services. See also our explainer on SOC 2 compliance.

FedRAMP and NIST SP 800-53: the control is CA-8

FedRAMP is established at 44 U.S.C. 3608 as the government-wide programme providing a standardised, reusable approach to security assessment and authorization for cloud computing products and services that process unclassified information used by agencies, and the authorisation is granted by government rather than by a vendor. The control that actually requires the testing is NIST SP 800-53 CA-8: conduct penetration testing at an organization-defined frequency on organization-defined systems or components. NIST’s discussion states that penetration testing goes beyond automated vulnerability scanning and is conducted by agents and teams with demonstrable skills in network, operating system or application level security. Three enhancements matter when you read a proposal: CA-8(1) requires an independent testing agent or team free from conflicts of interest with the development, operation or management of the target; CA-8(2) covers red team exercises; CA-8(3) covers announced or unannounced attempts to bypass physical access controls. Sources: 44 U.S.C. 3608 and NIST SP 800-53 Rev. 5. See also our explainer on FedRAMP and our public sector page.

CMMC and NIST SP 800-171: an assessment cycle, not a test clause

CMMC is issued by the Department of Defense in 32 CFR part 170 and binds contract and subcontract awardees that process, store or transmit Federal Contract Information or Controlled Unclassified Information on contractor systems. Level 2 requirements are identical to NIST SP 800-171 Revision 2. The cadence is set by the assessment rules rather than by a testing clause: a Level 1 self-assessment is annual and submitted in SPRS with no plans of action permitted; a Level 2 self-assessment is conducted every three years with results in SPRS; a Level 2 certification assessment must be completed within three years of the CMMC Status Date; and affirmation is required at each assessment and annually thereafter. Neither CMMC nor NIST SP 800-171 names penetration testing as a requirement in the way PCI DSS does, so a test here is evidence for an assessment rather than a clause to satisfy. Sources: 32 CFR 170.14, 170.16 and 170.17, and NIST SP 800-171. Our government IT services page carries the acquisition side.

What to ask any penetration testing company

The quality gap between penetration testing companies is wide and is not visible in the proposal. Directory lists of top pen testing companies rank by marketing spend, not by testing depth, so use the questions below instead. These five questions separate human-led testing from a rebadged scan.

1. Who is testing, and what are their certifications? Ask for named testers with OSCP, CREST or GPEN, not a company-level claim.
2. Is a retest included in the price? If it is billed separately, the quote is not comparable to one that includes it.
3. Can I see a redacted sample report? A serious firm will send one. The report is the deliverable, so judge it before you buy.
4. What proportion of the work is manual? Automated scanning is a starting point. Business-logic flaws are only found by a person.
5. How are findings evidenced? Every finding should carry reproduction steps a developer can follow without you in the room.

Five more, once a proposal is actually in front of you

The five above separate a human-led test from a rebadged scan. These five separate two human-led proposals from each other, and every one of them is answerable in a sentence by a firm that has thought about it.

1. Which methodology will you follow, and will the report cite it? Ask for a named reference: NIST SP 800-115, the OWASP Web Security Testing Guide with its scenario identifiers, PTES and its seven sections. A methodology a report cites is a methodology you can check.
2. How is severity scored? Ask for CVSS v4.0 vector strings and CWE identifiers, not the words high and critical. The vector is what lets you re-score a finding against your own environment, which is the whole point of the Environmental metric group.
3. Black box, grey box or white box, and why that one? A vendor with a reason is telling you how they think. The PCI Security Standards Council’s own guidance notes that tests under PCI DSS are typically white box or grey box, and that a pure black box assessment may need more time, money and resources to produce the same deliverables.
4. What happens if you find something critical on day two? Ask for the escalation path and the stop condition, and ask for both to be in the rules of engagement rather than in an email. A firm that only reports criticals at the end is selling you a document, not a service.
5. Who holds the report and the evidence afterwards, and how is it transmitted and stored? NIST SP 800-53 notes that penetration testing may expose information protected by law or regulation, and that rules of engagement and contracts are where expectations for protecting it are set. Get the answer before the test, not after the report is emailed.

Where to go next

Split by what you are trying to do. Sthenos publishes the reference material and the service pages separately, so a reader scoping a test and a reader checking a requirement do not have to read each other’s page.

Frequently asked questions

How long does a penetration test take?

Most pen testing services quote two to four weeks end to end for a single application or network segment: roughly ten working days of testing, then reporting. Full-scope red team engagements run six to twelve weeks.

What is the difference between a vulnerability assessment and penetration testing?

A vulnerability assessment identifies and ranks known weaknesses using automated scanning across a wide surface. A penetration test is human-led and proves exploitability and business impact on a narrower scope. Regulated programmes typically run continuous assessment plus an annual test.

Will testing disrupt production systems?

Testing is scheduled around your change windows, and destructive techniques such as denial-of-service are excluded unless you request them in writing. Escalation contacts are agreed before testing starts so anything unexpected is stopped immediately.

Do you test cloud environments?

Yes, across AWS, Azure and Google Cloud, covering identity and role configuration, storage exposure, network boundaries and infrastructure-as-code. Note that cloud providers require notification for certain test types, which we handle as part of scoping.

What do we receive at the end?

A technical findings report with severity ratings, evidence and reproduction steps; an executive summary written for a non-technical reader; a remediation session with your engineers; and a retest with an updated report once fixes are in place.

Do you work with government agencies?

Yes. Roughly a third of our work is public sector, and engagements are scoped against NIST SP 800-115 and NIST 800-171 where controlled unclassified information is in play. The remainder of our work is commercial, and the methodology is the same in both.

Will a penetration test expose our confidential data?

Testing can reach data, which is why the handling of it is written down before testing starts rather than afterwards. NIST SP 800-53 makes the point directly: penetration testing may result in the exposure of information protected by laws or regulations, and rules of engagement, contracts or other appropriate mechanisms are how expectations for protecting that information are set. In practice that means the scope agreement names what may be accessed and what may not, evidence should be captured as proof of access rather than as bulk extraction, and findings and evidence should be transmitted and stored by a method named in that agreement. Confidentiality terms are agreed in writing with the scope, before anything is touched.

Can you fix the vulnerabilities you find, or only report them?

Both. This page already sells the remediation half: developer remediation sessions, remediation roadmaps that turn a findings report into a sequenced plan with owners and dependencies, and application and cloud security work that closes the class of defect rather than the instance. The retest is included, so a fix we support is a fix we then re-verify. One caveat worth knowing: where a framework or an auditor requires the tester to be independent, keep the remediation work and the test with different parties. NIST SP 800-53 control enhancement CA-8(1) is the clause that names that independence, and it is the reason some programmes deliberately split the two.

How should severity be scored in a penetration test report?

The common answer is CVSS v4.0, published by FIRST, which describes it as an open framework for communicating the characteristics and severity of software vulnerabilities across four metric groups: Base, Threat, Environmental and Supplemental. Scores run from 0 to 10, and the published qualitative bands are None at 0.0, Low at 0.1 to 3.9, Medium at 4.0 to 6.9, High at 7.0 to 8.9 and Critical at 9.0 to 10.0. FIRST states that the use of these qualitative severity ratings is optional. Ask any vendor for the vector string alongside the number, because the vector is what lets your team re-score a finding for your own environment, and ask whether a finding that is a class of defect rather than a single instance will also carry a CWE identifier.

How often should we run a penetration test?

It depends on which requirement is asking. PCI DSS guidance states testing at least annually and after any significant change, with the entity deciding what counts as significant. The HIPAA Security Rule requires a periodic technical and nontechnical evaluation rather than a test on a fixed cadence. CMMC sets an assessment cycle rather than a testing clause, with Level 1 self-assessed annually and Level 2 assessed every three years, affirmed annually. NIST SP 800-53 CA-8 leaves the frequency for the organisation to define. Absent a requirement, the practical answer is annually plus after any significant release or architecture change.

Do we need a black box test for the result to be realistic?

Usually not, and the assumption is expensive. The PCI Security Standards Council defines black box testing as testing performed without prior knowledge of the internal structure, design or implementation, and notes that a black box assessment may require more time, money and resources to produce the same deliverables. Its guidance also records that PCI DSS penetration tests are typically performed as white box or grey box assessments, and that these yield more accurate results and a more comprehensive test of the security posture than a pure black box assessment. Choose black box when the question genuinely is what an unaided outsider can achieve. Choose grey box when the question is how exposed you are.

Is a penetration test report the same as a certification?

No. A report is evidence that a test happened, against a stated scope, with stated findings and their retest status. Certification against a framework is issued under that framework’s own scheme by an assessor accredited to it; the PCI Security Standards Council, for example, describes Qualified Security Assessor companies as independent security organisations qualified by the council to validate an entity’s adherence to PCI DSS. A penetration testing firm can give you the report and, where it is agreed in the scope, a letter confirming the test was performed and retested. It cannot give you a certificate, and a badge offered as an output of a test is a marketing artefact rather than an assurance one.

Ready to scope a penetration test? Tell us what is in scope and what is driving the requirement, and we will come back with a fixed-price proposal for penetration test services that names the testers, the standards, and the retest terms. Talk to our security team or call +1 301-793-3980.