Test against the benchmark your assessor will use.

The goal of this service is to stop your application being the route an attacker takes to your source code or your data, and to produce findings that hold up when someone else checks them. We test from the outside and the inside against published benchmarks, report in terms your engineers can act on, and retest after remediation. For teams targeting DoD hosting, we prepare the full ATO package rather than handing you a test report and wishing you luck.

Who it is for. Teams shipping software that holds sensitive data, teams whose customers now require a third party penetration test before they will sign, and teams that need an Authority to Operate to host on a DoD system.

• Penetration testing combining the OSSTMM, PTES and OWASP methodologies, external and internal
• Application Security and Development STIG conduct, with checklist deliverables
• Web application, API and mobile application testing
• Static, dynamic, interactive and mobile application security testing, plus software composition analysis
• Checks for misconfiguration in the underlying operating system and software components, not only the application code
• Continuous security monitoring and DevSecOps, where testing needs to be part of the pipeline rather than an annual event
• Detailed findings with actionable remediation guidance, and a retest afterwards

A penetration test is only as useful as the standard it was run against. We test to published benchmarks so the findings are defensible to an assessor, a customer's security team, or an authorising official, rather than being one consultant's opinion.

• OWASP Top 10 and OWASP Application Security Verification Standard, for the coverage level your customers and assessors expect
• OWASP Web Security Testing Guide and Mobile Application Security Verification Standard, where mobile is in scope
• OWASP API Security Top 10, which is where most modern findings actually land
• DISA Application Security and Development STIG, applied control by control with results delivered as checklists rather than prose
• OSSTMM and PTES for the testing methodology itself, external and internal
• CIS Benchmarks for the operating system and platform layer beneath the application

If the goal is to host on a DoD system, the penetration test is one artifact in a much larger package. We prepare the whole thing, at the impact level you are actually targeting.

• Impact level scoping under the DISA Cloud Computing SRG, so the boundary and the control set match the level you need rather than the highest one you have heard of
• IL2, IL4 and IL5 hosting paths on authorised cloud environments, with the boundary drawn before implementation begins
• Application Security and Development STIG conduct, remediation, and the .ckl checklists an assessor will ask for
• SCAP and ACAS scan results, with false positives triaged rather than passed through raw
• System Security Plan authored against the applicable NIST SP 800-53 baseline, plus the supporting body of evidence
• POA&M development and management through the RMF steps, packaged for eMASS submission
• Independent security assessment support through to the authorising official's decision

Worth being clear before you plan around one. A DISA Provisional Authorization is a reusable assessment artifact that an authorising official may rely on. It is not itself an Authority to Operate, and PAs are granted per service rather than across an entire cloud provider. An agency AO still issues your ATO, and the boundary they authorise is yours, not your hosting provider's. We tell clients this early because programmes that plan around a PA as though it were an ATO lose months.

A report you can hand to a customer going through their own security review, a fixed set of issues rather than a list of them, and where DoD hosting is the goal, a package an authorising official can act on. Clients commonly pair an annual penetration test with ongoing monitoring.

Which impact level do we actually need?

It follows from the data, not from ambition. IL2 covers non-critical unclassified information, IL4 covers CUI, and IL5 covers higher sensitivity CUI and national security systems. Targeting a higher level than your data requires adds cost and months. We scope this first, because everything downstream depends on it.

Our cloud provider has a Provisional Authorization. Are we covered?

No. A PA is a reusable assessment artifact an authorising official may rely on, granted per service rather than across a whole cloud. Your application boundary still needs its own assessment and its own ATO from an agency AO. Programmes that plan around a provider's PA as though it were their own ATO routinely lose months.

Do you deliver STIG results as a report or as checklists?

Checklists. Assessors want .ckl files and SCAP results they can open, not a narrative describing them. We also triage false positives before delivery rather than passing raw scan output through, because an inflated finding count costs you credibility and remediation time.

Can you test without disrupting production?

Yes. Scope, timing and rules of engagement are agreed in writing before anything starts, and testing against a staging environment is normal where production risk is unacceptable.