7. Requirements #

This section defines the minimum requirements that must be captured, reviewed, and traced from intake through acceptance. Requirements must be testable, linked to acceptance criteria, and reflected in the release evidence package.

7.1 Business requirements #

Business requirements must clearly describe the problem to solve, stakeholders, and success criteria in terms that can be tested in UAT. Each requirement must indicate the data it touches (including whether personal information is involved), the expected user roles, and any operational constraints (e.g., hours of operation, performance expectations, reporting needs). Acceptance criteria must be specific and observable (e.g., “Repair manager can upload up to PENDING: MAX UPLOAD SIZE __ MB JPEG/PNG photos per claim; system confirms AV scan pass and strips EXIF before storage”). Where the solution replaces or integrates with existing workflows, the requirement must state dependencies and any migration needs (data mapping, historical access).

7.2 Security requirements #

Security requirements must be explicit and verifiable. They include identity, authorization, encryption, logging, testing, and operational controls the solution must implement.

• Identity and authorization. The solution must support SSO with CLD’s IdP and enforce MFA for administrative roles and any access to Restricted data. Roles must implement least privilege and be documented as part of the design. PENDING: IdP/protocols (e.g., OIDC/SAML); SCIM vs JIT; standard roles and scopes.

• Data residency and protection. Personal information must be stored and accessed in Canada by default; any exception requires a risk assessment and DPIA with safeguards (encryption with Canadian key custody, access controls, logging) and an expiry. Data at rest must use strong encryption (e.g., AES‑256 or equivalent), and data in transit must use TLS 1.2+ with modern ciphers. Keys and secrets must be stored in a vault/KMS and rotated on a defined cadence.

• API and file‑upload protections. APIs must use OAuth 2.0/OIDC (user flows via Authorization Code + PKCE; service‑to‑service via Client Credentials or mTLS), implement input validation/schema enforcement, rate‑limiting, and error‑handling that avoids information leakage. File uploads must be constrained by type and size, scanned by AV/antimalware before processing, and (for images) have sensitive metadata removed unless specifically required. PENDING: Allowed grants, token TTLs, scope conventions; allowed MIME types; max size; AV behavior; EXIF rule.

• Logging and monitoring. The solution must emit SIEM‑ready logs for authentication, authorization decisions, permission/role changes, account lifecycle events, admin/config changes, API calls, data exports/uploads (including AV result), and security control blocks (e.g., WAF). Logs must include who/when/where/what/outcome and a correlation ID, use synchronized UTC time, and redact secrets. Vendors will operate a SIEM per contract; CLD may require log forwarding. PENDING: CLD forwarding decision; ingestion method; minimum fields; retention months.

• Testing and assurance. The build must pass SAST and SCA (with SBOM) and secrets scanning; web/API endpoints must pass DAST; containers/IaC must be scanned when applicable. Pentests by an independent party are required annually (and after material changes), with remediation plans and verification of fixes. PENDING: SBOM format; fail‑gate thresholds; pentest report sharing scope.

• Vulnerability remediation. Findings must be triaged and remediated within defined SLAs; emergency containment is required for exploited issues. Proposed SLAs: Critical 7 days, High 30 days, Medium 60 days, Low 90 days. Exceptions require ISO approval, a POA&M, and expiry. PENDING: Confirm or adjust SLAs; notification thresholds.

7.3 Privacy requirements #

Privacy requirements ensure lawful, fair, and minimal processing aligned with PIPEDA and Quebec Law 25. The solution must collect only the data necessary for the stated purpose, present only what is needed to each role, and support configurable retention and secure deletion (including crypto‑shred for cloud objects). Data used in non‑production environments must be anonymized or otherwise de‑identified unless a documented exception is granted.

Subject‑rights requests (access, correction, deletion) must be supported operationally—either through product features or via an administrative process documented by the vendor—and the solution must allow CLD to export, correct, or delete an individual’s data within required timelines. Cross‑border transfers require prior approval and a DPIA; subprocessors must be disclosed and approved in advance, with equivalent obligations contractually flowed down. PENDING: Forbidden data categories; retention targets for claims photos/docs/comms; residency exception approval workflow; DPIA template link.

Traceability and acceptance All business, security, and privacy requirements must be traceable to acceptance criteria and test cases. At Pre‑Production, the evidence package must show how each requirement was verified (e.g., test results for MFA enforcement, log samples demonstrating required fields, SBOM attached, DAST report summary, data‑flow diagram updated). At Go‑Live, any requirements with planned follow‑ups must be listed with owners and dates in a POA&M.