Red Teaming: every screen, column and action¶
The smallest module in the product, and deliberately so — a red team engagement produces a handful of findings that matter rather than a list to work through.
The audit list¶
An engagement is tracked as an audit, with the same columns as the other assessment modules:
| Column | What it holds |
|---|---|
| Request Info | Who commissioned the engagement, when, and the request ID |
| Audit Details | The engagement name and its target |
| Vulnerabilities | How many findings it produced, with the severity split |
| Audit Properties | Type, cycle, scope and whether the engagement is considered |
| Audit Status | The engagement's state |
Row actions — five¶
| Action | What it does |
|---|---|
| View Vulnerabilities | The findings from this engagement |
| Assign Auditors | Who runs the engagement |
| Edit Audit Details | Name, dates, scope and properties |
| View Status History | Every status change, with who made it |
| Delete Audit | Soft delete |
The menu is shorter than VA's or AppSec's on purpose. There is no re-audit, no audit chain and no severity configuration, because a red team engagement is a discrete exercise rather than a repeating scan — you commission a new one, you do not re-run the old one.
The findings list¶
| Column | What it holds |
|---|---|
| VID | The finding's identifier, to quote in discussion |
| Vulnerability | What was achieved and how |
| Risk | The team's own rating |
| Status | Where the finding has got to |
The only row action is Delete Vulnerability. Findings are entered by the team as they work and edited in place, so there is no separate edit dialog to open.
Validation statusesSaved, Submitted, Approved, Closed, False Positive — the same five as¶
Application Security, in this module's own table.
Why the findings read differently¶
A scanner finding names a weakness. A red team finding names an outcome — domain admin obtained, customer data reachable, a payment altered — and then explains the path that produced it.
That has two consequences for anyone supporting this module:
- Risk is judged, not derived. There is no CVSS score behind it. The team rates the finding on what it let them do, so two findings with identical technical severity can be rated differently and both be right.
- The path matters more than the endpoint. A finding that chains four low-severity weaknesses is the point of the exercise, and closing any one link resolves it. Reading only the individual weaknesses misses what was actually demonstrated.
Detection is part of the result¶
A red team engagement tests the response as much as the estate. Whether the activity was noticed, by what, and how quickly, is recorded with the findings — and an engagement where nothing was detected is a significant result even if few technical weaknesses were found.
This is why the module has no SLA columns. A red team finding is not a queue item with a remediation clock; it is evidence for a decision about defensive capability.