This guide provides a recommended reading order and orientation for new readers of the OWASP Autonomous Penetration Testing Standard. It does not create requirements. All requirements are defined in the domain READMEs.
APTS serves three primary audiences:
Read the Introduction first. It explains the standard's purpose, the eight domains, and compliance tiers. Pay particular attention to tier definitions, as they drive subsequent decisions.
Skim the Glossary to familiarize yourself with APTS-specific terminology. Key terms include the four autonomy levels (L1 Assisted through L4 Autonomous, defined in the Graduated Autonomy domain), the four asset criticality categories (Critical, Production, Non-Production, Unknown, defined in APTS-SE-005), and the distinction between MUST, SHOULD, and MAY per RFC 2119.
Read the Checklists appendix for your target tier. This provides a compact view of every requirement organized by tier and domain. You do not need to understand each requirement deeply at this stage; the goal is to see the full scope.
Before reading individual domains, skim the Cross-Domain Integration appendix. APTS domains are interdependent: a single event (such as a kill-switch activation or a scope violation) can trigger requirements across four or more domains simultaneously. Understanding these dependencies prevents the common mistake of implementing domains in isolation. The appendix includes event-triggered dependency maps, a suggested implementation sequence, and scenario walk-throughs.
Read the domain READMEs that are most relevant to your role:
| If You Are... | Start With These Domains |
|---|---|
| A platform architect | Scope Enforcement (SE), Safety Controls (SC), Graduated Autonomy (AL) |
| A security operations lead | Human Oversight (HO), Safety Controls (SC), Auditability (AR) |
| A compliance officer | Auditability (AR), Reporting (RP), Supply Chain Trust (TP); also see Compliance Matrix for regulatory framework mappings |
| A CISO evaluating vendors or an internal platform | All domains via Vendor Evaluation Guide |
| An enterprise security team building an internal autonomous pentest platform | All domains. Start with Scope Enforcement (SE), Safety Controls (SC), Human Oversight (HO), then Auditability (AR) |
| A security professional reviewing a platform | Scope Enforcement (SE), Safety Controls (SC), Auditability (AR), Manipulation Resistance (MR), Reporting (RP), then the Verification subsections for the claimed tier |
| An AI/ML engineer | Manipulation Resistance (MR), Graduated Autonomy (AL), Supply Chain Trust (TP) |
Each domain README contains the full normative requirements with rationale and verification procedures. Framework mappings (NIST CSF, ISO 27001, NIST AI RMF, SOC 2, PCI DSS, GDPR) are in the Compliance Matrix. Domains are not independent; refer to Cross-Domain Integration to understand how requirements in your focused domains connect to others.
Each domain includes an Implementation Guide with practical guidance for every requirement. These guides provide implementation approaches, key considerations, and common pitfalls. They are informative (non-normative); the domain READMEs are the authoritative source.
Depending on your role:
| Document | Type | Purpose |
|---|---|---|
| Introduction | Normative | Framework overview, tiers, how to use this standard |
| Glossary | Informative | Term definitions |
| Domain READMEs (8) | Normative | Full requirements with rationale and verification |
| Implementation Guides (8) | Informative | Practical implementation guidance per requirement |
| Checklists | Informative | Quick-reference verification checklists by tier |
| Compliance Matrix | Informative | Mappings to NIST CSF, ISO 27001, NIST AI RMF, SOC 2, PCI DSS, GDPR |
| Vendor Evaluation Guide | Informative | Customer-facing vendor assessment guide |
| Customer Acceptance Testing | Informative | Hands-on verification tests |
| Incident Response Integration | Informative | Operational integration guidance |
| Cross-Domain Integration | Informative | Cross-domain trigger mappings and dependency analysis |
| Testing Phase Mapping | Informative | Requirements mapped to pentesting lifecycle phases |
| Evidence Request Checklist | Informative | Lightweight checklist of artifacts customers and reviewers can request |
| Conformance Claim Schema | Informative | Illustrative machine-readable schema for structured conformance claims |
| Conformance Claim Template | Informative | Optional template for platform operators documenting conformance |
| Evidence Package Manifest | Informative | Illustrative manifest for finding evidence, provenance, and downstream handoff |
| Rules of Engagement Template | Informative | Illustrative machine-readable Rules of Engagement starter template |
| Advisory Requirements | Informative | Best-practice requirements not gated to any compliance tier |
Q: Do I need to implement all 173 requirements?
No. Start with Tier 1 (72 requirements). Tier 2 and Tier 3 add requirements progressively for cumulative totals of 157 and 173. An additional 10 advisory practices live in the Advisory Requirements appendix under the APTS-<DOMAIN>-A0x identifier pattern; advisory practices are not required for conformance at any tier. See Introduction: Compliance Tiers for details.
Q: What if my platform meets most but not all Tier 1 requirements? APTS does not award partial credit. A platform must meet 100% of requirements for its claimed tier. Address gaps before claiming a tier.
Q: Are the Implementation Guides mandatory? No. Implementation Guides are informative. They suggest approaches but do not define requirements. The domain READMEs contain all normative requirements.
Q: How does APTS relate to PTES, WSTG, or OSSTMM? APTS is a governance framework, not a testing methodology. Autonomous systems should follow established testing methodologies (PTES, WSTG, OSSTMM) while operating under APTS governance controls.
Q: Do I need to get certified? No. See the Introduction for the full verification model. Platforms are assessed against the requirements, conformance is documented, and customers may independently verify claims using the Vendor Evaluation Guide.
Q: When should I re-evaluate against APTS? Re-evaluate after major platform changes, security incidents, autonomy level changes, material dependency changes, or when the APTS standard releases a new version. At minimum, re-evaluate annually.
Q: How much time should I budget for APTS? For platform operators (vendors, service providers, and enterprise security teams running internal platforms): plan 2-3 days to read and understand requirements for your target tier, plus 1-2 days per domain for detailed implementation planning. For customers evaluating an external vendor or assessing an internal platform: plan 1-2 weeks using the Vendor Evaluation Guide to review evidence and demonstrations of key safety controls. If conducting optional Customer Acceptance Testing, add 1-2 weeks for test execution and analysis.