# 8. Security Monitoring & Auditing — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: security_monitoring_auditing.md — every feature, sub-feature, and rule covered

---

## Test Execution Policy
- Zero tolerance: any deviation from documented behavior = FAILED = bug
- Every bug is immediately logged/reported (Bug ID, feature, sub-feature, expected vs actual, severity) and fixed 100% before the group passes
- Feature group passes only at 100% test pass rate

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 8.1 Login Activity Logging | Log fields per event | TC-SA-01-08-001 |
| 8.1 Login Activity Logging | Real-time security dashboard with live feed | TC-SA-01-08-002 |
| 8.1 Login Activity Logging | Filtering and search | TC-SA-01-08-003 |
| 8.1 Login Activity Logging | Per-account login history | TC-SA-01-08-004 |
| 8.1 Login Activity Logging | Pattern views (failures clustered by IP/account/location) | TC-SA-01-08-005 |
| 8.1 Login Activity Logging | Retention per policy with secure, access-controlled storage | TC-SA-01-08-006 |
| 8.1 Login Activity Logging | Export of login logs (filtered) | TC-SA-01-08-007 |
| 8.1 Login Activity Logging | Append-only integrity | TC-SA-01-08-008 |
| 8.1 Login Activity Logging | Rule: logs immutable; no role can edit or delete entries | TC-SA-01-08-009 |
| 8.1 Login Activity Logging | Rule: sensitive values (passwords, full OTP codes) never written to logs | TC-SA-01-08-010 |
| 8.1 Login Activity Logging | Rule: dashboard shows summaries/trends with drill-down; full log never dumped at once | TC-SA-01-08-011 |
| 8.1 Login Activity Logging | Rule: failed attempts for non-existent emails logged (enumeration detection) | TC-SA-01-08-012 |
| 8.1 Login Activity Logging | Rule: retention followed; purge automatic and recorded | TC-SA-01-08-013 |
| 8.1 Login Activity Logging | Rule: exports access-controlled and the export action audit-logged | TC-SA-01-08-014 |
| 8.2 Security Audit Trail | Audit event coverage | TC-SA-01-08-015 |
| 8.2 Security Audit Trail | Each event records actor, action, target, before/after, timestamp, IP, device | TC-SA-01-08-016 |
| 8.2 Security Audit Trail | Tamper-evidence: immutable, integrity-checked; alteration attempts logged and alerted | TC-SA-01-08-017 |
| 8.2 Security Audit Trail | Search and filter | TC-SA-01-08-018 |
| 8.2 Security Audit Trail | Point-in-time policy snapshots | TC-SA-01-08-019 |
| 8.2 Security Audit Trail | Retention per compliance requirements (strictest regulation governs) | TC-SA-01-08-020 |
| 8.2 Security Audit Trail | Export for external audits in standard formats | TC-SA-01-08-021 |
| 8.2 Security Audit Trail | Compliance dashboard | TC-SA-01-08-022 |
| 8.2 Security Audit Trail | Rule: trail not modifiable; alteration attempts logged and alerted | TC-SA-01-08-023 |
| 8.2 Security Audit Trail | Rule: privileged data access audit-logged | TC-SA-01-08-024 |
| 8.2 Security Audit Trail | Rule: before/after state captured for configuration and permission changes | TC-SA-01-08-025 |
| 8.2 Security Audit Trail | Rule: retention follows the strictest applicable regulation | TC-SA-01-08-026 |
| 8.2 Security Audit Trail | Rule: exports are read-only copies; source trail immutable and authoritative | TC-SA-01-08-027 |
| 8.2 Security Audit Trail | Rule: trail spans all modules with the same immutability guarantees | TC-SA-01-08-028 |
| 8.3 Suspicious Activity Detection and Alerts | Detection rules | TC-SA-01-08-029 |
| 8.3 Suspicious Activity Detection and Alerts | Alert severity levels | TC-SA-01-08-030 |
| 8.3 Suspicious Activity Detection and Alerts | Alert delivery (in-app, email, SMS for critical) | TC-SA-01-08-031 |
| 8.3 Suspicious Activity Detection and Alerts | Alert triage workflow | TC-SA-01-08-032 |
| 8.3 Suspicious Activity Detection and Alerts | One-click context linking to underlying events | TC-SA-01-08-033 |
| 8.3 Suspicious Activity Detection and Alerts | Rule configuration | TC-SA-01-08-034 |
| 8.3 Suspicious Activity Detection and Alerts | False-positive feedback | TC-SA-01-08-035 |
| 8.3 Suspicious Activity Detection and Alerts | Incident summary | TC-SA-01-08-036 |
| 8.3 Suspicious Activity Detection and Alerts | Rule: alerts are decision support, not automatic action (except configured auto-block) | TC-SA-01-08-037 |
| 8.3 Suspicious Activity Detection and Alerts | Rule: every alert carries a full context link | TC-SA-01-08-038 |
| 8.3 Suspicious Activity Detection and Alerts | Rule: false-positive marking recorded, feeds tuning, does not delete the alert/events | TC-SA-01-08-039 |
| 8.3 Suspicious Activity Detection and Alerts | Rule: critical alerts delivered by SMS as well as in-app/email | TC-SA-01-08-040 |
| 8.3 Suspicious Activity Detection and Alerts | Rule: unacknowledged critical alerts remain highlighted until actioned | TC-SA-01-08-041 |
| 8.3 Suspicious Activity Detection and Alerts | Rule: rule and threshold changes audit-logged | TC-SA-01-08-042 |
| 8.4 Support for Regular Security Audits | Pre-built audit reports | TC-SA-01-08-043 |
| 8.4 Support for Regular Security Audits | Point-in-time policy snapshots | TC-SA-01-08-044 |
| 8.4 Support for Regular Security Audits | Evidence export packages | TC-SA-01-08-045 |
| 8.4 Support for Regular Security Audits | Audit scheduling | TC-SA-01-08-046 |
| 8.4 Support for Regular Security Audits | Findings tracking | TC-SA-01-08-047 |
| 8.4 Support for Regular Security Audits | Compliance dashboard | TC-SA-01-08-048 |
| 8.4 Support for Regular Security Audits | Record of completed audits | TC-SA-01-08-049 |
| 8.4 Support for Regular Security Audits | Rule: evidence packages are read-only exports; source remains immutable | TC-SA-01-08-050 |
| 8.4 Support for Regular Security Audits | Rule: policy snapshots prove historical configuration | TC-SA-01-08-051 |
| 8.4 Support for Regular Security Audits | Rule: findings tracked until explicitly closed with evidence; open findings always visible | TC-SA-01-08-052 |
| 8.4 Support for Regular Security Audits | Rule: scheduling reminders recur per the configured cadence | TC-SA-01-08-053 |
| 8.4 Support for Regular Security Audits | Rule: provision of evidence to external parties access-controlled and logged | TC-SA-01-08-054 |
| 8.4 Support for Regular Security Audits | Rule: completed audit records retained per policy; baseline for the next cycle | TC-SA-01-08-055 |

## 8.1 Login Activity Logging

### TC-SA-01-08-001 — Log fields per event complete and accurate
**Type:** Positive
**Covers:** 8.1 → Log fields per event
**Preconditions:** Login events produced (success and failure, all methods); the login activity log.
**Steps:**
1. Produce login events: password success, password failure, OTP success, social login, SSO login, and a blocked attempt.
2. Locate each in the login activity log.
3. Verify each field: user (or attempted email), timestamp, outcome, failure reason (where failed), IP, device, approximate location, authentication method.
**Expected Result:** Every event carries all fields (user or attempted email, timestamp, outcome, failure reason for failures, IP, device, approximate location, authentication method); each field matches the actual event; no field is missing; the failure reasons are specific (invalid password, OTP expired, IP blocked, location blocked, locked, suspended).
**Priority:** Critical

### TC-SA-01-08-002 — Real-time security dashboard with live feed
**Type:** Positive
**Covers:** 8.1 → Real-time security dashboard: live feed of recent login activity with success/failure indicators
**Preconditions:** The Security Monitoring dashboard; ongoing login activity.
**Steps:**
1. Open the Security Monitoring dashboard.
2. Observe the live feed of recent login activity.
3. Produce a new login (success and failure) and verify it appears in the feed.
4. Verify the success/failure indicators.
**Expected Result:** The dashboard shows a live feed of recent login activity; new events appear in near real time; each event has a success/failure indicator; method and location indicators are shown; the feed is a scrolling list (not a static snapshot).
**Priority:** High

### TC-SA-01-08-003 — Filtering and search across all dimensions
**Type:** Positive
**Covers:** 8.1 → Filtering and search: by user, outcome, failure reason, method, IP, location, and time range
**Preconditions:** A diverse set of login events; the dashboard filter controls.
**Steps:**
1. Filter by user and verify only that user's events show.
2. Filter by outcome (success/failure/block) and verify.
3. Filter by failure reason (e.g., "invalid password") and verify.
4. Filter by method, IP, location, and time range and verify each.
5. Combine filters and verify the intersection.
**Expected Result:** Each filter dimension (user, outcome, failure reason, method, IP, location, time range) returns the correct events; combined filters return the intersection; the filters are responsive; the results match the underlying log exactly.
**Priority:** High

### TC-SA-01-08-004 — Per-account login history: full chronological record
**Type:** Positive
**Covers:** 8.1 → Per-account login history: the full chronological login record for a single user
**Preconditions:** A user with many login events over time; the per-account history view.
**Steps:**
1. Open the user's full login history.
2. Verify it is the complete chronological record (all events, oldest to newest).
3. Verify each event's details (method, IP, location, outcome, failure reason).
4. Cross-check a sample against the global log.
**Expected Result:** The per-account history shows the full chronological login record for the single user (no gaps); each event's details are complete; the record matches the global log for that user; the history supports the "many failures then a success" investigation pattern.
**Priority:** High

### TC-SA-01-08-005 — Pattern views: failures clustered by IP, account, or location
**Type:** Positive
**Covers:** 8.1 → Pattern views: failures clustered by IP, by account, or by location over a selected window
**Preconditions:** Failure events with known clustering (by IP, by account, by location); the pattern views.
**Steps:**
1. Select a time window and open the pattern view clustered by IP.
2. Verify the failures are grouped by source IP with counts.
3. Repeat clustered by account and by location.
4. Identify a cluster (e.g., one account, many failures, one unfamiliar location).
**Expected Result:** The pattern views cluster failures by IP, by account, and by location over the selected window; the counts match the actual events; a brute-force-then-compromise cluster is identifiable (many failures then a success); the views support the investigation workflow.
**Priority:** High

### TC-SA-01-08-006 — Retention per policy with secure, access-controlled storage
**Type:** Positive
**Covers:** 8.1 → Retention per policy with secure, access-controlled storage
**Preconditions:** The retention policy known; login logs within and beyond the retention period; access control on the log storage.
**Steps:**
1. Verify login logs within the retention period are accessible.
2. Verify logs beyond the retention period are purged.
3. Verify the log storage is access-controlled (only authorized roles can access).
4. Verify the storage is secure (encrypted at rest per the platform standard).
**Expected Result:** Login logs are retained per policy (accessible within the period, purged beyond it); the storage is access-controlled (unauthorized roles cannot access the raw log); the storage is secure; the retention matches the configured policy.
**Priority:** Medium

### TC-SA-01-08-007 — Export of login logs (filtered) for audits and incident reports
**Type:** Positive
**Covers:** 8.1 → Export of login logs (filtered) for audits and incident reports
**Preconditions:** A filtered login log set; export access.
**Steps:**
1. Apply a filter (e.g., failures by reason over a period).
2. Export the filtered log.
3. Verify the export contains exactly the filtered events with all fields.
4. Verify the export is in a usable format for the review pack.
**Expected Result:** The filtered login log is exported (only the filtered events, not the full log); the export contains all fields per event; the format is usable for audits and incident reports; the export is complete and accurate; the export action is audit-logged.
**Priority:** High

### TC-SA-01-08-008 — Append-only integrity: entries cannot be edited or deleted
**Type:** Negative
**Covers:** 8.1 → Append-only integrity: entries cannot be edited or deleted by any role
**Preconditions:** Existing login log entries; Super Admin access (the highest role).
**Steps:**
1. As the Super Admin, attempt to edit an existing login log entry.
2. Attempt to delete an existing entry.
3. Observe the outcomes.
4. Verify the entries are unchanged.
**Expected Result:** The edit is rejected (no edit capability exists); the delete is rejected (no delete capability exists); the entries remain unchanged; the log is append-only; the attempts are logged (as unauthorized modification attempts); no role, including Super Admin, can modify the log.
**Priority:** Critical

### TC-SA-01-08-009 — Logs immutable; no role can edit or delete entries
**Type:** Negative
**Covers:** 8.1 → Rule: logs are append-only and immutable; no role, including Super Admin, can edit or delete entries
**Preconditions:** Existing login log entries; multiple roles including Super Admin; direct storage access (if available for the test).
**Steps:**
1. As each role (including Super Admin), attempt to edit or delete an entry via the UI.
2. Attempt a direct modification (via a crafted request or storage access, if the test environment allows).
3. Verify all entries are unchanged.
4. Verify the integrity check passes.
**Expected Result:** No role can edit or delete a login log entry (all attempts rejected); direct modification attempts are rejected or detected; all entries remain unchanged; the integrity check passes; the immutability holds for forensics and audits; the attempts are logged.
**Priority:** Critical

### TC-SA-01-08-010 — Sensitive values never written to logs
**Type:** Negative
**Covers:** 8.1 → Rule: sensitive values (passwords, full OTP codes) are never written to logs
**Preconditions:** Login events with known passwords and OTP codes; the login activity log; log storage access.
**Steps:**
1. Produce login events with known passwords and OTP codes (success and failure).
2. Search the login activity log for the plaintext passwords.
3. Search for the full OTP codes.
4. Search the log storage (raw) for the sensitive values.
**Expected Result:** No plaintext password appears in the log; no full OTP code appears in the log; only the event and its non-sensitive context are recorded (the failure reason "invalid password" is present, but not the password itself); a full review finds zero sensitive values; the rule holds across all event types.
**Priority:** Critical

### TC-SA-01-08-011 — Dashboard shows summaries/trends with drill-down; full log never dumped at once
**Type:** Edge
**Covers:** 8.1 → Rule: log volume is high; the dashboard shows summaries and trends with drill-down; the full log is never dumped into the UI at once
**Preconditions:** A high volume of login events; the dashboard.
**Steps:**
1. Open the dashboard with a high event volume.
2. Verify it shows summaries and trends (not the full raw log).
3. Drill down from a summary/trend to individual events.
4. Verify the full log is never rendered at once in the UI.
**Expected Result:** The dashboard shows summaries and trends (aggregated views) under high volume; drilling down reveals individual events on demand; the full log is never dumped into the UI at once (no performance degradation, no unbounded render); the drill-down is accurate (matches the underlying events).
**Priority:** Medium

### TC-SA-01-08-012 — Failed attempts for non-existent emails logged (enumeration detection)
**Type:** Positive
**Covers:** 8.1 → Rule: failed attempts for non-existent emails are logged (with the attempted email) to support enumeration-attack detection
**Preconditions:** Login attempts with non-existent emails; the login activity log.
**Steps:**
1. Attempt logins with several non-existent emails.
2. Locate the attempts in the login activity log.
3. Verify the attempted email is recorded (subject to privacy handling).
4. Verify the attempts support enumeration-attack detection (clusterable by IP).
**Expected Result:** The failed attempts for non-existent emails are logged with the attempted email (subject to the privacy handling of the raw email); the attempts are clusterable by IP (enumeration detection); the logging does not reveal account existence to the attacker (the user-facing response is generic); the events support the enumeration-attack investigation.
**Priority:** Medium

### TC-SA-01-08-013 — Retention followed; purge automatic and recorded
**Type:** Edge
**Covers:** 8.1 → Rule: retention follows policy; after the period, logs are purged automatically and the purge is recorded
**Preconditions:** Login logs beyond the retention period; the purge cycle.
**Steps:**
1. Wait for/trigger the automatic purge cycle.
2. Verify the beyond-retention logs are purged.
3. Inspect the purge record (what was purged, when).
4. Verify no manual purge step is required.
**Expected Result:** The beyond-retention logs are purged automatically (no manual action); the purge is recorded (what was purged, when); no log data persists beyond the retention period; the purge record is itself immutable (part of the audit trail); the retention matches the policy.
**Priority:** Medium

### TC-SA-01-08-014 — Exports access-controlled and the export action audit-logged
**Type:** Positive
**Covers:** 8.1 → Rule: exports are access-controlled and the export action is audit-logged (who exported what, when)
**Preconditions:** Export access for authorized and unauthorized roles; an export to perform.
**Steps:**
1. As an unauthorized role, attempt to export the login log (verify it is blocked).
2. As an authorized role, export a filtered log.
3. Verify the export action is audit-logged (who exported what, when).
4. Verify the audit entry matches the actual export.
**Expected Result:** The export is access-controlled (unauthorized roles cannot export); the authorized export succeeds; the export action is audit-logged with the actor, the scope exported (what), and the timestamp (when); the audit entry matches the actual export; no export occurs without an audit entry.
**Priority:** High

## 8.2 Security Audit Trail

### TC-SA-01-08-015 — Audit event coverage across all security-relevant categories
**Type:** Positive
**Covers:** 8.2 → Audit event coverage: authentication events, permission changes, account status changes, admin actions, policy changes, IP/location rule changes, privileged data access
**Preconditions:** Events produced in each category; the Security Audit Trail.
**Steps:**
1. Produce an event in each category (authentication, permission change, account status change, admin action like forced logout, security policy change, IP/location rule change, privileged data access).
2. Locate each in the Security Audit Trail.
3. Verify each is present with its details.
**Expected Result:** All seven event categories are present in the audit trail; each event is recorded with its details; no category is missing; the coverage is comprehensive (the security-relevant subset across all modules); the events support the point-in-time reconstruction.
**Priority:** Critical

### TC-SA-01-08-016 — Each event records actor, action, target, before/after, timestamp, IP, device
**Type:** Positive
**Covers:** 8.2 → Each event records: actor, action, target, before/after state (where applicable), timestamp, IP, and device
**Preconditions:** Audit events produced (including a configuration change with before/after); the audit trail.
**Steps:**
1. Produce several audit events (including a permission change and a policy change).
2. Locate each in the trail.
3. Verify actor, action, target, before/after state (where applicable), timestamp, IP, and device on each.
**Expected Result:** Every event records the actor, the action, the target, the before/after state (where applicable — configuration and permission changes), the timestamp, the IP, and the device; no field is missing; the before/after state is accurate (supports reconstruction); the entries are complete.
**Priority:** Critical

### TC-SA-01-08-017 — Tamper-evidence: immutable, integrity-checked; alteration attempts logged and alerted
**Type:** Negative
**Covers:** 8.2 → Tamper-evidence: entries are immutable and integrity-checked; alteration attempts are themselves logged and alerted
**Preconditions:** Existing audit trail entries; an alteration attempt to make; the integrity check.
**Steps:**
1. Run the integrity check on the trail (verify it passes on an unaltered trail).
2. Attempt to alter an entry (via a crafted request or storage access, if the test environment allows).
3. Verify the alteration is rejected or detected.
4. Verify the alteration attempt is logged and raises an alert.
5. Re-run the integrity check and verify it flags the tamper attempt.
**Expected Result:** The integrity check passes on an unaltered trail; the alteration attempt is rejected or detected; the attempt is itself logged and raises an alert (tamper-evidence); the integrity check flags the tamper attempt; the trail remains authoritative; no silent alteration is possible.
**Priority:** Critical

### TC-SA-01-08-018 — Search and filter by actor, actor type, action type, target, time range
**Type:** Positive
**Covers:** 8.2 → Search and filter: by actor, actor type, action type, target, and time range
**Preconditions:** A diverse set of audit events; the trail filter controls.
**Steps:**
1. Filter by actor and verify only that actor's events show.
2. Filter by actor type (e.g., "Administrator") and verify.
3. Filter by action type (e.g., "forced logout") and verify.
4. Filter by target and time range and verify each.
5. Combine filters (e.g., actor type "Administrator" + a quarter's date range) and verify.
**Expected Result:** Each filter dimension (actor, actor type, action type, target, time range) returns the correct events; combined filters return the intersection; the "Administrator + quarter" filter returns exactly the admin actions for the period (the external-audit use case); the results match the trail exactly.
**Priority:** High

### TC-SA-01-08-019 — Point-in-time policy snapshots
**Type:** Positive
**Covers:** 8.2 → Point-in-time policy snapshots: what the security policy was at a given date
**Preconditions:** Security policy changes made on known dates; the snapshot capability.
**Steps:**
1. Generate a point-in-time policy snapshot for a past date (before a known change).
2. Verify the snapshot reflects the policy as it was on that date (not the current policy).
3. Generate a snapshot for a later date (after the change) and verify it reflects the new policy.
4. Verify the snapshots are accurate for the period-specific audit question.
**Expected Result:** The point-in-time snapshot for a given date reflects the security policy exactly as it was on that date (historical, not current); snapshots before and after a change differ correctly; the snapshots support the period-specific audit question ("what was the configuration during the quarter?"); the snapshots are accurate and complete.
**Priority:** High

### TC-SA-01-08-020 — Retention per compliance requirements (strictest regulation governs)
**Type:** Positive
**Covers:** 8.2 → Retention per compliance requirements (the strictest applicable regulation governs)
**Preconditions:** The compliance retention requirements known (multiple jurisdictions); audit trail entries within and beyond the retention.
**Steps:**
1. Verify the retention period applied is the strictest applicable regulation (not the shortest).
2. Verify entries within the retention are accessible.
3. Verify entries beyond the retention are handled per the strictest requirement.
4. Verify the retention is documented.
**Expected Result:** The retention period is the strictest applicable regulation across the jurisdictions (not the shortest or a local minimum); entries within the retention are accessible; entries beyond are handled per the strictest requirement; the retention choice is documented; the compliance requirement is met.
**Priority:** Medium

### TC-SA-01-08-021 — Export for external audits in standard formats
**Type:** Positive
**Covers:** 8.2 → Export for external audits in standard formats
**Preconditions:** A filtered audit trail set; the export capability; the auditor's required format.
**Steps:**
1. Filter the trail (e.g., admin actions over a quarter).
2. Export in the standard format the auditor requires.
3. Verify the export contains the filtered events with all fields.
4. Verify the format is standard and usable by the auditor.
**Expected Result:** The filtered audit trail is exported in a standard format (usable by external auditors); the export contains the filtered events with all fields (actor, action, target, before/after, timestamp, IP, device); the format is standard (not proprietary); the export is complete and accurate; the export is a read-only copy.
**Priority:** High

### TC-SA-01-08-022 — Compliance dashboard: open items, recent privileged actions, audit-readiness
**Type:** Positive
**Covers:** 8.2 → Compliance dashboard: open items, recent privileged actions, and audit-readiness indicators
**Preconditions:** Open compliance items; recent privileged actions; the compliance dashboard.
**Steps:**
1. Open the compliance dashboard.
2. Verify the open items are shown.
3. Verify the recent privileged actions are shown.
4. Verify the audit-readiness indicators are shown and accurate.
**Expected Result:** The compliance dashboard shows the open items (unresolved compliance matters); the recent privileged actions (admin actions, privileged data access); and the audit-readiness indicators; each is accurate and current; the dashboard supports the ongoing compliance posture; the data matches the underlying trail.
**Priority:** Medium

### TC-SA-01-08-023 — Trail not modifiable; alteration attempts logged and alerted
**Type:** Negative
**Covers:** 8.2 → Rule: the audit trail is not modifiable by any role; attempts to alter it are logged and raise an alert
**Preconditions:** Existing audit trail entries; multiple roles including Super Admin; an alteration attempt.
**Steps:**
1. As each role (including Super Admin), attempt to modify a trail entry via the UI.
2. Attempt a direct modification (crafted request or storage access, if the test environment allows).
3. Verify all attempts are rejected or detected.
4. Verify each attempt is logged and raises an alert.
**Expected Result:** No role can modify the audit trail (all attempts rejected); direct modification attempts are rejected or detected; each attempt is logged and raises an alert (tamper-evidence); the trail remains unmodified and authoritative; the alerts are visible in security monitoring; no silent modification is possible.
**Priority:** Critical

### TC-SA-01-08-024 — Privileged data access audit-logged
**Type:** Positive
**Covers:** 8.2 → Rule: privileged data access (an admin viewing a user's personal data or a minor's record) is audit-logged
**Preconditions:** An admin with access to personal data and minor records; the audit trail.
**Steps:**
1. As an admin, view a user's personal data.
2. As an admin, view a minor's record.
3. Locate both accesses in the audit trail.
4. Verify the actor, target, timestamp, and context on each.
**Expected Result:** The privileged data access (viewing personal data, viewing a minor's record) is audit-logged; each entry records the actor, the target (the user/minor), the timestamp, and the context; the logging supports the right-to-access and safeguarding obligations; no privileged access is unlogged; the entries are in the audit trail.
**Priority:** High

### TC-SA-01-08-025 — Before/after state captured for configuration and permission changes
**Type:** Positive
**Covers:** 8.2 → Rule: before/after state is captured for configuration and permission changes so any change can be reconstructed
**Preconditions:** Configuration and permission changes made; the audit trail.
**Steps:**
1. Make a configuration change (e.g., a security policy value) and a permission change.
2. Locate both in the audit trail.
3. Verify the before/after state is captured on each.
4. Verify the change can be reconstructed (not just detected) from the before/after.
**Expected Result:** The configuration change records the before/after state (the old and new values); the permission change records the before/after permission sets; both can be reconstructed (not just detected) from the trail; the before/after is accurate; the reconstruction supports the audit ("what exactly changed?").
**Priority:** High

### TC-SA-01-08-026 — Retention follows the strictest applicable regulation
**Type:** Edge
**Covers:** 8.2 → Rule: retention periods follow the strictest applicable regulation across the jurisdictions
**Preconditions:** Multiple jurisdictions with different retention requirements; the strictest known; audit trail entries.
**Steps:**
1. Identify the strictest applicable retention across the operating jurisdictions.
2. Verify the trail's retention matches the strictest (not a shorter local requirement).
3. Verify entries are retained for the strictest period.
4. Verify the choice is documented and defensible.
**Expected Result:** The trail's retention is the strictest applicable regulation (the longest/most protective across jurisdictions); entries are retained for that period; the choice is documented (which regulation governs and why); the compliance requirement is met; no entry is purged before the strictest period.
**Priority:** Medium

### TC-SA-01-08-027 — Exports are read-only copies; source trail immutable and authoritative
**Type:** Edge
**Covers:** 8.2 → Rule: exports are read-only copies; the source trail remains immutable and authoritative
**Preconditions:** An audit trail export produced; the source trail.
**Steps:**
1. Export a filtered audit trail.
2. Verify the export is a read-only copy (cannot be used to modify the source).
3. Verify the source trail is unchanged and remains authoritative.
4. Verify modifying the export does not affect the source.
**Expected Result:** The export is a read-only copy (a snapshot, not a live view); the source trail remains immutable and authoritative (the export does not become the system of record); modifying the export file does not affect the source; the source trail's integrity check still passes; the distinction (copy vs authoritative) is clear.
**Priority:** Medium

### TC-SA-01-08-028 — Trail spans all modules with the same immutability guarantees
**Type:** Positive
**Covers:** 8.2 → Rule: the audit trail spans all modules (not only authentication); the same immutability guarantees apply
**Preconditions:** Security-relevant events from multiple modules (not only authentication); the audit trail.
**Steps:**
1. Produce security-relevant events in multiple modules (e.g., a permission change in Role Management, a policy change in System Settings, an admin action in User Management).
2. Locate all in the audit trail.
3. Verify the same immutability guarantees apply to each (no module's events are modifiable).
4. Attempt to modify an event from a non-authentication module (verify it is rejected).
**Expected Result:** The audit trail spans all modules (not only authentication); security-relevant events from each module are present; the same immutability guarantees apply to every module's events (none are modifiable); the modification attempt on a non-authentication event is rejected; the trail is a unified system of record.
**Priority:** High

## 8.3 Suspicious Activity Detection and Alerts

### TC-SA-01-08-029 — Detection rules fire on the documented patterns
**Type:** Positive
**Covers:** 8.3 → Detection rules: impossible travel, velocity logins, repeated failures, new device + new location, bulk account access attempts, OTP delivery failure spikes, lockout spikes
**Preconditions:** The detection rules enabled; scenarios for each pattern.
**Steps:**
1. Trigger each pattern: impossible travel (two continents in a short window), velocity logins, repeated failures, new device + new location, bulk account access from one source, an OTP delivery failure spike, a lockout spike.
2. Verify each raises an alert.
3. Verify each alert identifies the pattern.
**Expected Result:** Each documented pattern raises an alert (impossible travel, velocity, repeated failures, new device + new location, bulk access, OTP delivery spike, lockout spike); each alert identifies the pattern; the detection is in near real time; the alerts link to the underlying events; the rules fire correctly (no missed patterns).
**Priority:** Critical

### TC-SA-01-08-030 — Alert severity levels: info, warning, critical
**Type:** Positive
**Covers:** 8.3 → Alert severity levels: info, warning, critical
**Preconditions:** Alerts of each severity produced; the dashboard.
**Steps:**
1. Produce an info-level alert, a warning-level alert, and a critical-level alert.
2. Verify each is labeled with its severity.
3. Verify the severity is consistent with the pattern (e.g., impossible travel = critical).
4. Verify the severity drives the delivery (critical → SMS).
**Expected Result:** Each alert is labeled with its severity (info, warning, or critical); the severity is consistent with the pattern's risk; the severity drives the delivery (critical alerts are delivered by SMS as well); the labels are clear; the severities are accurate.
**Priority:** High

### TC-SA-01-08-031 — Alert delivery: in-app dashboard, email, and SMS for critical
**Type:** Positive
**Covers:** 8.3 → Alert delivery: in-app dashboard, email, and (for critical) SMS to the on-duty admin
**Preconditions:** A critical alert and a non-critical alert to produce; the on-duty admin's channels.
**Steps:**
1. Produce a critical alert and verify it is delivered in-app, by email, and by SMS to the on-duty admin.
2. Produce a non-critical alert and verify it is delivered in-app and by email (not SMS).
3. Verify the on-duty admin receives the critical SMS.
**Expected Result:** The critical alert is delivered in-app, by email, and by SMS to the on-duty admin (seen even if the dashboard is not open); the non-critical alert is delivered in-app and by email (not SMS); the delivery matches the severity; the on-duty admin is correctly identified; the deliveries are logged.
**Priority:** High

### TC-SA-01-08-032 — Alert triage workflow: acknowledge, assign, resolve with outcome notes
**Type:** Positive
**Covers:** 8.3 → Alert triage workflow: acknowledge, assign to an admin, resolve with outcome notes
**Preconditions:** An alert to triage; the triage workflow.
**Steps:**
1. Acknowledge the alert and verify the state changes to acknowledged.
2. Assign it to an admin and verify the assignment.
3. Resolve it with outcome notes and verify the resolution.
4. Verify the workflow states are tracked (unacknowledged → acknowledged → assigned → resolved).
**Expected Result:** The triage workflow works: the alert is acknowledged (state changes), assigned to an admin (the assignment is recorded), and resolved with outcome notes (the notes are captured); the states are tracked in order; the resolution is complete (the alert is closed with the outcome); the workflow supports the investigation (the actions are recorded).
**Priority:** High

### TC-SA-01-08-033 — One-click context: each alert links to the underlying events
**Type:** Positive
**Covers:** 8.3 → One-click context: each alert links to the underlying login/audit events for fast triage
**Preconditions:** An alert with underlying events; the alert detail view.
**Steps:**
1. Open an alert (e.g., impossible travel).
2. Verify the underlying events are shown (e.g., the two login events side by side: times, locations, devices, methods).
3. Use the one-click link to the full event context.
4. Verify the context is complete (no hunting through raw logs).
**Expected Result:** Each alert shows the underlying events (e.g., the two logins side by side with times, locations, devices, methods); the one-click link takes the admin to the full event context; the context is complete (triage does not require hunting through raw logs); the link is accurate (the events match the alert); the fast triage is supported.
**Priority:** High

### TC-SA-01-08-034 — Rule configuration: enable/disable, tune thresholds and windows
**Type:** Positive
**Covers:** 8.3 → Rule configuration: enable/disable rules, tune thresholds and windows
**Preconditions:** Super Admin access to the detection rule configuration; a rule to tune.
**Steps:**
1. Open the detection rule configuration.
2. Disable a rule and verify it no longer fires.
3. Re-enable it and verify it fires again.
4. Tune a threshold/window (e.g., the impossible-travel window) and verify the new value applies.
5. Verify the change is audit-logged.
**Expected Result:** Rules can be enabled/disabled (a disabled rule does not fire; a re-enabled rule fires); thresholds and windows are tunable (the new value applies to detection); the configuration is per-rule; the change is audit-logged (who changed which rule, before/after values); the tuning supports false-positive reduction.
**Priority:** High

### TC-SA-01-08-035 — False-positive feedback feeds rule tuning
**Type:** Positive
**Covers:** 8.3 → False-positive feedback: marking an alert a false positive feeds rule tuning to reduce noise
**Preconditions:** A recurring benign pattern (e.g., a staff member's regular travel) raising alerts; the false-positive marking.
**Steps:**
1. Mark a recurring benign alert as a false positive.
2. Verify the marking is recorded.
3. Verify the false-positive data feeds rule tuning (the rule can be adjusted to reduce the noise).
4. Tune the rule (e.g., the impossible-travel window) and verify the noise reduces.
**Expected Result:** The false-positive marking is recorded (the alert is not deleted); the false-positive data feeds rule tuning (the admin can see the recurring pattern and adjust the rule); the tuning reduces the noise (the benign pattern no longer alerts); the marking and the tuning are logged; the underlying events are preserved.
**Priority:** Medium

### TC-SA-01-08-036 — Incident summary: resolved alerts compile into an incident record
**Type:** Positive
**Covers:** 8.3 → Incident summary: resolved alerts compile into an incident record with timeline and actions
**Preconditions:** A resolved alert (with the full triage workflow completed); the incident record.
**Steps:**
1. Resolve an alert with the full triage (acknowledge, assign, actions, resolve with notes).
2. Verify the resolved alert compiles into an incident record.
3. Verify the record has the full timeline (detection, acknowledgment, actions, resolution).
4. Verify the record is reviewable in the weekly security review.
**Expected Result:** The resolved alert compiles into an incident record; the record has the full timeline (detection time, acknowledgment time, the actions taken, the resolution); the outcome notes are included; the record is reviewable (the weekly security review); the incident is complete (no missing steps); the record is retained.
**Priority:** Medium

### TC-SA-01-08-037 — Alerts are decision support, not automatic action (except configured auto-block)
**Type:** Edge
**Covers:** 8.3 → Rule: alerts are decision support, not automatic action — except where a rule is explicitly configured to auto-block
**Preconditions:** A detection rule that raises an alert (not auto-block); a rule configured to auto-block (e.g., deny-list hits).
**Steps:**
1. Trigger a non-auto-block rule and verify it raises an alert (no automatic action is taken).
2. Verify the admin must triage (the account is not auto-suspended, sessions not auto-terminated).
3. Trigger an auto-block rule (e.g., a deny-list hit) and verify it blocks without an alert triage step.
4. Verify the distinction is clear.
**Expected Result:** The non-auto-block rule raises an alert (decision support) and takes no automatic action (the admin triages and decides); the auto-block rule (explicitly configured) blocks without an alert triage step (e.g., deny-list hits block immediately); the distinction is clear (which rules auto-block is explicit); the auto-block is logged; the alert-based rules require human decision.
**Priority:** High

### TC-SA-01-08-038 — Every alert carries a full context link
**Type:** Positive
**Covers:** 8.3 → Rule: every alert carries a full context link to the underlying events
**Preconditions:** Multiple alerts of different types; the alert detail views.
**Steps:**
1. Open several alerts of different types (impossible travel, repeated failures, lockout spike).
2. Verify each carries a full context link to the underlying events.
3. Follow each link and verify the context is complete.
4. Verify no alert lacks the context link.
**Expected Result:** Every alert carries a full context link to the underlying events (no alert is a bare notification); following the link shows the complete context (the events, times, locations, devices, methods); the context is accurate (matches the alert); no alert requires hunting through raw logs; the rule holds for all alert types.
**Priority:** High

### TC-SA-01-08-039 — False-positive marking recorded, feeds tuning, does not delete the alert/events
**Type:** Edge
**Covers:** 8.3 → Rule: marking an alert a false positive is recorded and feeds rule tuning; it does not delete the alert or the underlying events
**Preconditions:** An alert to mark as a false positive; the alert and its underlying events.
**Steps:**
1. Mark the alert as a false positive.
2. Verify the marking is recorded (the alert is not deleted).
3. Verify the underlying events are preserved (not deleted).
4. Verify the false-positive data is available for rule tuning.
**Expected Result:** The false-positive marking is recorded (the alert remains in the history, marked as a false positive); the underlying events are preserved (not deleted — the forensic record is intact); the false-positive data feeds rule tuning (available for analysis); the marking does not erase the evidence; the record supports the noise-reduction tuning.
**Priority:** Medium

### TC-SA-01-08-040 — Critical alerts delivered by SMS as well as in-app/email
**Type:** Positive
**Covers:** 8.3 → Rule: critical alerts are delivered by SMS as well as in-app/email so they are seen even if the dashboard is not open
**Preconditions:** A critical alert to produce; the on-duty admin's SMS channel; the dashboard closed.
**Steps:**
1. Produce a critical alert with the dashboard closed.
2. Verify the on-duty admin receives the SMS.
3. Verify the in-app and email deliveries also occur.
4. Verify the SMS is seen even though the dashboard is not open.
**Expected Result:** The critical alert is delivered by SMS to the on-duty admin (seen even if the dashboard is not open); the in-app and email deliveries also occur; the SMS is the additional channel for critical severity; the on-duty admin is correctly identified; the deliveries are logged; the critical alert is not missed.
**Priority:** High

### TC-SA-01-08-041 — Unacknowledged critical alerts remain highlighted until actioned
**Type:** Positive
**Covers:** 8.3 → Rule: unacknowledged critical alerts remain highlighted on the dashboard and in the compliance view until actioned
**Preconditions:** A critical alert left unacknowledged; the dashboard and compliance view.
**Steps:**
1. Produce a critical alert and leave it unacknowledged.
2. Verify it remains highlighted on the dashboard.
3. Verify it remains highlighted in the compliance view.
4. Acknowledge it and verify the highlight clears.
**Expected Result:** The unacknowledged critical alert remains highlighted on the dashboard (not buried); it remains highlighted in the compliance view (visible to the compliance posture); the highlight persists until the alert is actioned (acknowledged); after acknowledgment, the highlight clears; the rule ensures critical alerts are not missed.
**Priority:** High

### TC-SA-01-08-042 — Rule and threshold changes audit-logged
**Type:** Positive
**Covers:** 8.3 → Rule: rule and threshold changes are audit-logged (who changed which rule, before/after values)
**Preconditions:** Detection rule changes to make; audit log access.
**Steps:**
1. Change a detection rule (enable/disable, tune a threshold/window).
2. Locate the change in the audit log.
3. Verify the actor, the rule changed, and the before/after values.
4. Verify no rule change is unlogged.
**Expected Result:** Every rule and threshold change is audit-logged with the actor (who), the rule changed (which), and the before/after values; no rule change is unlogged; the log supports the review ("what detection rules were active when?"); the before/after is accurate; the log is exportable.
**Priority:** High

## 8.4 Support for Regular Security Audits

### TC-SA-01-08-043 — Pre-built audit reports over a selected period
**Type:** Positive
**Covers:** 8.4 → Pre-built audit reports: authentication events, permission changes, admin actions, and policy state over a selected period
**Preconditions:** Events in each category over a period; the audit support section.
**Steps:**
1. Select an audit period (e.g., the trailing 12 months).
2. Generate the pre-built reports: authentication events, permission changes, admin actions, policy state.
3. Verify each report covers the selected period.
4. Verify the reports are complete and accurate.
**Expected Result:** The pre-built reports are generated for the selected period (authentication events, permission changes, admin actions, policy state); each report covers the period (no gaps); the reports are complete and accurate (match the underlying data); the reports are usable for the audit; the generation is efficient (pre-built, not manual).
**Priority:** High

### TC-SA-01-08-044 — Point-in-time policy snapshots for the audit period
**Type:** Positive
**Covers:** 8.4 → Point-in-time policy snapshots: the security policy as it was at a given date
**Preconditions:** Security policy changes during the audit period; the snapshot capability.
**Steps:**
1. Generate a policy snapshot at the period start.
2. Generate a policy snapshot at the period end.
3. Verify each reflects the policy as it was on that date.
4. Verify the snapshots support the period-specific audit question.
**Expected Result:** The policy snapshot at the period start reflects the policy as it was then; the snapshot at the period end reflects the policy as it was then; the snapshots are accurate (historical, not current); they support the period-specific audit question ("what was the configuration at the start/end of the period?"); the snapshots are included in the evidence package.
**Priority:** High

### TC-SA-01-08-045 — Evidence export packages in standard formats
**Type:** Positive
**Covers:** 8.4 → Evidence export packages: bundled logs, reports, and policy snapshots in standard formats for auditors
**Preconditions:** The audit period selected; the evidence package capability.
**Steps:**
1. Generate the evidence package for the period (authentication logs summary, admin action trail, permission-change history, policy snapshots at start/end, current detection-rule state).
2. Verify the package is bundled (all components in one export).
3. Verify the format is standard (usable by auditors).
4. Verify the package is complete against the auditor's requested scope.
**Expected Result:** The evidence package is generated (bundled: authentication logs summary, admin action trail, permission-change history, policy snapshots at start/end, current detection-rule state); the package is in a standard format (usable by external auditors); the package is complete (all components present); the package can be reviewed for completeness against the scope; the package is a read-only export.
**Priority:** High

### TC-SA-01-08-046 — Audit scheduling: recurring reminders
**Type:** Positive
**Covers:** 8.4 → Audit scheduling: recurring reminders for internal review cadence and external audit dates
**Preconditions:** The audit scheduling configuration; an internal review cadence and an external audit date.
**Steps:**
1. Configure the internal review cadence and the external audit date.
2. Verify the recurring reminders are generated per the cadence.
3. Verify the external audit date reminder is generated.
4. Verify the reminders are received (in-app/email).
**Expected Result:** The audit scheduling generates recurring reminders for the internal review cadence (per the configured frequency); the external audit date reminder is generated (ahead of the date); the reminders are received (in-app/email); the cadence is configurable; the reminders ensure audits are not missed; the scheduling is logged.
**Priority:** Medium

### TC-SA-01-08-047 — Findings tracking: log, assign, track to closure
**Type:** Positive
**Covers:** 8.4 → Findings tracking: log audit findings, assign remediation owners, track status to closure
**Preconditions:** Audit findings to log (e.g., "two admin accounts lacked 2FA for a 3-day window"); the findings tracking.
**Steps:**
1. Log an audit finding with the auditor's reference.
2. Assign a remediation owner and a due date.
3. Track the finding's status (open → in remediation → closed).
4. Close the finding with remediation evidence.
5. Verify the full lifecycle is tracked.
**Expected Result:** The finding is logged (with the auditor's reference); a remediation owner and due date are assigned; the status is tracked (open → in remediation → closed); the finding is closed with remediation evidence (the evidence is attached); the full lifecycle is tracked; the finding is not closed without evidence; the tracking supports the compliance dashboard.
**Priority:** High

### TC-SA-01-08-048 — Compliance dashboard: open findings, upcoming audits, audit-readiness
**Type:** Positive
**Covers:** 8.4 → Compliance dashboard: open findings, upcoming audits, and audit-readiness indicators
**Preconditions:** Open findings; upcoming audits; the compliance dashboard.
**Steps:**
1. Open the compliance dashboard.
2. Verify the open findings are shown.
3. Verify the upcoming audits are shown.
4. Verify the audit-readiness indicators are shown and accurate.
**Expected Result:** The compliance dashboard shows the open findings (unresolved, with owners and due dates); the upcoming audits (scheduled, with dates); and the audit-readiness indicators; each is accurate and current; the dashboard supports the audit preparation; the data matches the underlying tracking; the open findings are always visible.
**Priority:** Medium

### TC-SA-01-08-049 — Record of completed audits with evidence packages and outcomes
**Type:** Positive
**Covers:** 8.4 → Record of completed audits with their evidence packages and outcomes
**Preconditions:** A completed audit (with its evidence package, findings, and remediation outcomes); the completed-audit record.
**Steps:**
1. Complete an audit (evidence package provided, findings logged and closed).
2. Record the completed audit with its evidence package, findings, and remediation outcomes.
3. Verify the record is stored and retrievable.
4. Verify the record forms the baseline for the next audit cycle.
**Expected Result:** The completed audit is recorded (with its evidence package, the findings, and the remediation outcomes); the record is stored and retrievable; the record documents the audit (what was provided, the findings, the closures); the record forms the baseline for the next audit cycle (the next audit starts from a documented baseline); the record is retained per policy.
**Priority:** Medium

### TC-SA-01-08-050 — Evidence packages are read-only exports; source remains immutable
**Type:** Edge
**Covers:** 8.4 → Rule: evidence packages are read-only exports; the source logs and trail remain immutable and authoritative
**Preconditions:** An evidence package generated; the source logs and trail.
**Steps:**
1. Generate an evidence package.
2. Verify the package is a read-only export (a snapshot, not a live view).
3. Verify the source logs and trail are unchanged and remain authoritative.
4. Verify modifying the package does not affect the source.
**Expected Result:** The evidence package is a read-only export (a snapshot); the source logs and trail remain immutable and authoritative (the package does not become the system of record); modifying the package file does not affect the source; the source's integrity check still passes; the distinction (copy vs authoritative) is clear; the package is for the auditor's use.
**Priority:** Medium

### TC-SA-01-08-051 — Policy snapshots prove historical configuration
**Type:** Positive
**Covers:** 8.4 → Rule: policy snapshots allow proving what the configuration was historically, not just what it is now
**Preconditions:** A policy change made during the audit period; snapshots before and after.
**Steps:**
1. Generate a snapshot before the change and a snapshot after.
2. Verify the before-snapshot shows the old configuration (historical proof).
3. Verify the after-snapshot shows the new configuration.
4. Verify the snapshots answer the period-specific question ("what was the configuration in March?").
**Expected Result:** The before-snapshot proves the historical configuration (what it was, not just what it is now); the after-snapshot shows the new configuration; the snapshots answer the period-specific audit question (e.g., "what was the 2FA policy in March?"); the historical proof is accurate; the snapshots support the finding remediation (documenting the policy change that closed the gap).
**Priority:** Medium

### TC-SA-01-08-052 — Findings tracked until explicitly closed with evidence; open findings always visible
**Type:** Edge
**Covers:** 8.4 → Rule: findings remain tracked until explicitly closed with remediation evidence; open findings are always visible on the compliance dashboard
**Preconditions:** Findings in various states (open, in remediation, closed); the compliance dashboard.
**Steps:**
1. Log findings and leave some open (not closed).
2. Verify the open findings are always visible on the compliance dashboard.
3. Attempt to close a finding without remediation evidence (verify it is blocked).
4. Close a finding with evidence and verify it moves to closed.
**Expected Result:** The open findings are always visible on the compliance dashboard (not hidden); a finding cannot be closed without remediation evidence (the closure is blocked); a finding with evidence is closed (moves to closed); the findings remain tracked until explicitly closed; the rule ensures no finding is silently dropped; the visibility supports the audit readiness.
**Priority:** High

### TC-SA-01-08-053 — Scheduling reminders recur per the configured cadence
**Type:** Positive
**Covers:** 8.4 → Rule: audit scheduling reminders recur per the configured cadence so audits are not missed
**Preconditions:** The audit scheduling configured with a cadence (e.g., quarterly internal review); the reminder generation.
**Steps:**
1. Configure the internal review cadence (e.g., quarterly).
2. Verify the reminders recur per the cadence (one per quarter).
3. Verify the cadence is consistent (no missed or duplicate reminders).
4. Verify the reminders are received on schedule.
**Expected Result:** The scheduling reminders recur per the configured cadence (one per period, e.g., quarterly); the cadence is consistent (no missed or duplicate reminders); the reminders are received on schedule (ahead of the review date); the cadence is configurable; the rule ensures audits are not missed; the recurrence is logged.
**Priority:** Medium

### TC-SA-01-08-054 — Provision of evidence to external parties access-controlled and logged
**Type:** Positive
**Covers:** 8.4 → Rule: provision of evidence to external parties is access-controlled and logged (what was shared, with whom, when)
**Preconditions:** An evidence package to share with an external auditor; the provision capability; the compliance log.
**Steps:**
1. As an unauthorized role, attempt to provision the evidence package (verify it is blocked).
2. As an authorized role, provision the package to the external auditor through the secure channel.
3. Verify the provision is logged (what was shared, with whom, when).
4. Verify the log entry matches the actual provision.
**Expected Result:** The provision is access-controlled (unauthorized roles cannot share the evidence); the authorized provision succeeds (through the secure channel); the provision is logged with what was shared (the package), with whom (the auditor), and when (the timestamp); the log entry matches the actual provision; no provision occurs without a log entry; the compliance log records the provision.
**Priority:** High

### TC-SA-01-08-055 — Completed audit records retained per policy; baseline for the next cycle
**Type:** Positive
**Covers:** 8.4 → Rule: completed audit records are retained per policy and form the baseline for the next audit cycle
**Preconditions:** Completed audit records; the retention policy; the next audit cycle.
**Steps:**
1. Verify the completed audit records are retained per policy (accessible within the retention).
2. Verify the records are retrievable for the next audit cycle.
3. Verify the next audit starts from the documented baseline (the prior record).
4. Verify the retention matches the policy.
**Expected Result:** The completed audit records are retained per policy (accessible within the retention period); the records are retrievable (the next audit can reference the prior baseline); the next audit starts from the documented baseline (the prior record's findings and outcomes); the retention matches the policy; the records form a continuous audit history; the baseline is clear.
**Priority:** Medium