# Scope Leakage Audit: Engagement Data Template

A useful first review needs only a small set of completed, sanitized engagements. Start with recent, comparable work. Ten or more engagements improves pattern coverage; smaller samples can still expose record-quality questions but cannot establish recurring behavior.

Use [the blank template](../../assets/audit/scope-leakage-audit-template.csv) and [example rows](../../assets/audit/scope-leakage-audit-example-rows.csv). The examples are illustrative only.

## Sanitize before use or sharing

Do **not** include client names, identifiable targets, URLs, domains, IP ranges, vulnerabilities, exploit details, findings, evidence, screenshots, credentials, tokens, API keys, source code, secrets, raw test notes, or customer contacts.

Use an anonymous ID such as `ANON-014`. Generalize a scope note to `multi-role SaaS application with SSO`, not a product name or implementation detail. The template is for estimating effort, not describing an attack surface.

## Required fields

| Column            | What to enter                                                                                                                                        |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `engagement_id`   | A unique anonymous ID, at most 120 characters.                                                                                                       |
| `assessment_type` | `Web Application Pentest`, `API Pentest`, `External Network Assessment`, or `Other`.                                                                 |
| Quoted effort     | `quoted_total_days`, or complete quoted components with the required completeness declaration. Must be greater than zero.                            |
| Actual effort     | `actual_total_days`, or complete actual components with the required completeness declaration. Must be greater than zero for a completed engagement. |

Use one consistent tester-day basis across rows. Do not enter cancelled/non-delivered work as zero actual effort.

## Useful optional fields

| Group            | Columns                                                                                          | Notes                                                                                                                                     |
| ---------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Timing           | `engagement_date`                                                                                | `YYYY`, `YYYY-MM`, or `YYYY-MM-DD`; use a real date from 1900–2100.                                                                       |
| Components       | Testing, reporting, retest day columns and `*_components_complete`                               | Components explain the effort basis. They are checked for reconciliation and never double-counted.                                        |
| Commercial       | `quoted_price`, `final_revenue`, `currency`, `internal_cost_per_day`                             | Currency is required whenever a monetary value is present. Monetary output remains coverage-limited.                                      |
| Billing evidence | `confirmed_unbilled_days`, `confirmed_change_order_revenue`                                      | Use only for facts that have been confirmed. Unbilled days cannot exceed actual effort; change-order revenue cannot exceed final revenue. |
| Complexity       | `complexity_band`, `authenticated_roles`, `multi_tenant`, `api_endpoint_band`, `retest_included` | Supports descriptive groupings, not causal attribution.                                                                                   |
| Context          | `scope_notes`                                                                                    | One short generalized sentence only.                                                                                                      |

`complexity_band` is `simple`, `typical`, `complex`, or `unknown`. Boolean fields are `true` or `false`. `api_endpoint_band` is one of `1-25`, `26-75`, `76-150`, `151-300`, or `300+`.

## File validation limits

The browser and command-line parser apply the same validation before analysis:

- UTF-8 CSV: at most 2 MB and 2,000 data rows;
- every field: at most 1,000 characters; unknown, duplicate, or empty headers are rejected;
- duplicate engagement IDs and malformed CSV quoting are rejected;
- numeric values use canonical base-10, non-negative decimals with at most two decimal places;
- each effort or confirmed-unbilled value is capped at 10,000 days; monetary values are capped at 100,000,000; authenticated roles must be a non-negative safe whole number;
- unsupported assessment types, complexity values, endpoint bands, dates, currencies, and inconsistent component totals are rejected.

A validation error blocks the entire audit. Rows are not silently skipped. Correct the source file and review it again.

## Interpreting output

The default under-/over-scope classification requires a variance outside both 10% and 0.25 day. Gross positive overruns, confirmed unbilled days, additional cost, and net gross-profit change are different measures. Missing commercial data remains unknown; mixed-currency monetary totals are suppressed. Review the row-coverage counts before using a financial figure.

Pattern labels are conservative: fewer than three records are insufficient, three to nine are a small sample, and ten or more are descriptive only. Overlapping groups must not be summed or interpreted as independent drivers.

For browser use and local handling, see the [browser audit guide](03-browser-audit-guide.md).