---
{
  "title": "The phases of a security assessment",
  "summary": "Use an organizing model while recognizing that professional work is iterative.",
  "topic": "offensive",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    4
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Technical Guide to Information Security Testing and Assessment",
      "url": "https://csrc.nist.gov/pubs/sp/800/115/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

A common teaching model describes reconnaissance, scanning, gaining access, maintaining access, and covering tracks. In professional assessments, activities are adapted to scope and objectives, and evidence is preserved rather than concealed. Reporting and remediation are central even when omitted from a simplified phase diagram. Defenders study persistence and evasion to recognize adversary behavior. Do not treat the historical model as a mandatory sequence or permission to imitate every step.

## In practice

A lab assessment stops after validating an access-control weakness and produces a report. Persistence is discussed from the defender’s perspective without unnecessary changes.

## A common misunderstanding

A phase called “covering tracks” is not a professional instruction to delete logs or hide authorized testing.

## Check your understanding

What should govern whether a phase is performed?

**Think it through:** The agreed objectives, rules of engagement, operational safety, and evidence requirements.

## A model for reasoning, not a checklist

Phase diagrams compress complex activity into memorable categories. Their value is helping learners ask what an actor knows, what access they possess, and which transition changes the defender's situation. Real activity may loop between stages, abandon an approach, or achieve an objective without malware or persistence. An exposed document could reveal useful information without any account compromise.

An assessment also contains work that older hacking diagrams overlook: establishing authority, identifying dependencies, protecting evidence, reporting uncertainty, and verifying fixes. These activities are not administrative extras. They determine whether technical observations become useful security improvements. A professional workflow should therefore show preparation and follow-up alongside technical exploration.

## Trace one fictional chain

A lab tester first learns that a demonstration application has separate student and tutor roles. Reviewing its interfaces reveals a grade endpoint. A controlled request using a synthetic student account retrieves a synthetic tutor-only record. The test objective is already satisfied: there is evidence of an authorization failure. Installing a persistent agent or deleting records would answer no additional agreed question.

A defender reviewing that sequence could ask which events are visible at each transition. Account creation may appear in identity logs, requests in application telemetry, and denied operations in authorization events. Missing telemetry becomes a finding about visibility, distinct from the application flaw itself. The same sequence therefore supports both prevention and detection discussions.

## Use phases with explicit outcomes

When planning an exercise, write an observable success criterion for each activity and the condition that ends it. Replace vague goals such as 'gain access' with a bounded statement, such as 'verify whether the test student can read the test tutor record.' Record unsuccessful approaches as coverage information rather than silently omitting them.

Sketch the lab chain as boxes connected by prerequisites. Mark which steps require an account, which generate logs, and which are unnecessary for the objective. This teaches dependencies and restraint more accurately than treating every historical phase as mandatory.

## Keep exploring

- [[reconnaissance]]
- [[port-scanning]]
- [[persistence]]
- [[penetration-test-reporting]]