## ADDED Requirements

### Requirement: Authorization precedes active testing

Active security testing (brute force, fuzzing) SHALL NOT begin until a written authorization
recording scope, source IPs, time window and emergency contact exists, a tested backup/snapshot is
taken, and dedicated test accounts are provisioned. Active tests SHALL run against a staging clone
or within a maintenance window, and SHALL NOT target real user accounts.

#### Scenario: Test blocked without authorization
- **WHEN** an operator attempts an active test without the recorded authorization and snapshot
- **THEN** the runbook procedure halts at the pre-flight gate and the test does not run

#### Scenario: Test uses dedicated accounts on staging
- **WHEN** a brute-force test runs
- **THEN** it targets a dedicated test account on staging (or in a maintenance window), never a
  real user

### Requirement: Pre-flight security checklist

The repo SHALL ship a pre-flight checklist (`docs/SECURITY_AUDIT_CHECKLIST.md`) covering the three
fronts — brute force, API/data access, inadvertent vectors — plus infrastructure. Each item SHALL
have an explicit pass/fail criterion.

#### Scenario: Checklist covers all fronts with criteria
- **WHEN** an operator opens the checklist
- **THEN** it contains markable items for each of the three fronts and infra, each with a defined
  pass/fail criterion

### Requirement: Non-destructive audit scripts

The repo SHALL provide audit scripts under `scripts/security/` (ACL probe, IDOR probe, brute-force
harness, CSRF PoC, web recon) that are non-destructive and parameterized with test-account
credentials rather than hard-coded production secrets.

#### Scenario: ACL probe reports access matrix
- **WHEN** the ACL probe runs with a portal test account
- **THEN** it reports, per model, whether read/write/create/unlink is allowed or denied, without
  modifying production data

#### Scenario: Scripts take credentials as parameters
- **WHEN** a script is invoked
- **THEN** target URL and credentials are supplied as parameters/env, with no secrets committed to
  the repo

### Requirement: Findings register tracks resolution

Findings SHALL be recorded in `docs/SECURITY_FINDINGS.md` with severity, evidence and status, and
each SHALL be tracked until resolved and verified.

#### Scenario: Confirmed findings tracked to closure
- **WHEN** the audit completes
- **THEN** the register lists H1–H5 (and any new findings) with severity and a status of
  resolved/verified or an owner and plan