Open the
Practice

An engagement begins before a tester sends a request and continues after the report lands. Someone selects the work and says why it matters. An accountable authority permits the test. The team turns that permission into a target, identities, conditions, limits, and a test design. A qualified tester applies the relevant method and records what happened. A reviewer may challenge the interpretation. The result reaches the people who can act on it. Technical questions, retesting, and lessons still need a place to go.

The line is simple; the decisions underneath it are not. Broad authorization does not tell a tester which API identities and actions are permitted. A scanner’s suggested weakness is not yet a reproduced finding. A change ticket is not proof that the original condition was fixed. Those distinctions are where a method becomes usable.

Here is the short version before anyone opens a document. The parts are useful individually; their connections are what make this a practice rather than a shelf of templates.

This is a map of the contribution, not a claim that a downloaded document makes a practice mature. The component register lets a reader enter through a problem, see the components that bear on it, and decide what to adopt or challenge. The consulting guidebook (§50.3) is one component in the delivery-and-support row—not the framework’s front door.

A practice lead facing a new testing demand could start with the engagement method: who authorizes the work, what a tester must know before starting, which specialist method applies, where a difficult result is reviewed, and who helps the owner afterward. The framework does not select the lead’s org chart; it exposes decisions that should not be left to chance.

A tester could start with the method for the target in front of them. An API assessment needs usable accounts across relevant roles, an endpoint and workflow picture, and a way to test ownership boundaries without confusing a tool’s suggestion with a demonstrated weakness. A physical assessment has different preparation and safety limits. Both should retain a clear trail from authorization through observation.

A reviewer or security partner could follow a report statement backward: what was observed, under which identity and target state, inside which scope, and what remained uncertain or untested? That trace matters when a finding is disputed or remediation changes the system.

CREST’s Guide to Penetration Testing already covers establishing and managing a penetration-testing programme, including preparation, testing, follow-up, and maturity assessment. OWASP’s testing guidance provides substantial domain method. Those are worth reading on their own terms.

The framework contributes an inspectable example of one implementation: connected, editable components showing how a team might translate guidance into working roles, methods, records, review points, and a correction loop. It is not a condensed digest of those sources, their replacement, or their endorsement. Its public materials earn a place only when people can use them to make or challenge a real decision. A neat index with thin methods would fail that test.

The first full reader route is a synthetic API engagement. It carries a reader from fictional authority and scope through two test identities, an API method, invented observations, evidence and review decisions, reporting, and a bounded retest condition. It also leaves one path untested: a scanner’s suspicion is not a result when the action sits outside the rules of engagement.

That paper route tests the framework harder than an umbrella document alone. Can a tester use it without inventing scope or technical steps? Can a lead adapt it without inheriting someone else’s staffing model? Can a reviewer trace one conclusion backward? If not, the problem is in the method or its connections—not in the reader’s willingness to study more files. It is an illustration, not an executed engagement or a measured validation of the framework.

The public material cannot grant permission to test, prescribe universal staffing, turn a severity score into a finding, or imply that a filled template proves a practice is operating. Adopters supply their own authority, obligations, people, systems of record, and risk decisions.

The baseline is human-led penetration testing. That matters: a team should be able to understand and improve the practice without first accepting an AI roadmap.

AI-assisted tools may compress preparation, explore more candidate paths, help organize evidence, and make some technical work easier to repeat. They may also increase the volume of uncertain output reaching people who must validate, explain, and route it. If that happens, the scarce resource may shift from generating candidates to deciding which results are true, consequential, authorized, and ready to move through an enterprise workflow.

An AI-infused practice belongs as a versioned extension, not as a retroactive claim about the human-led baseline. It would need to say where an agent may act, what it may read and send, how actions and evidence are recorded, who validates a finding, and where the work returns to a tester or another function. Claims about speed, quality, cost, and staffing would need observed measurements. Enthusiasm cannot stand in for a working method. The hardest part of that extension is a staffing question rather than a model question: what happens when agents produce more candidate findings than qualified people can validate. That's a piece I'm working on.