Canada Luggage Depot - Secure SDLC
Scope and Policy Applicability

. Scope

This policy governs all software and configuration delivered to CLD by third parties that could affect the confidentiality, integrity, availability, or lawful processing of CLD or client data. It applies from initial requirements through design, build, test, release, operation, maintenance, and retirement.

In scope

  • Solution types: custom or customized web/mobile applications, APIs and integrations (including service-to-service automations), data pipelines/jobs, low/no‑code apps, and significant SaaS configurations that introduce or modify business logic, data models, workflows, or security controls.

  • Delivery artifacts: application source/binaries, infrastructure‑as‑code/templates, container images, deployment scripts, configuration and secrets management, logging/telemetry schemas, and documentation required to deploy, operate, and support the solution.

  • Environments: development, test, staging, production, and disaster recovery environments; build/CI/CD systems to the extent they impact release integrity and security.

  • Parties: all external vendors and their approved subprocessors who build, host, operate, or maintain in‑scope solutions for CLD; CLD personnel responsible for acceptance, operation, vendor oversight, and incident response.

Out of scope

  • Pure off‑the‑shelf software used with standard settings and no material customization of logic or data model is governed by CLD’s Change and Configuration Management. However, baseline controls in related policies still apply (identity/SSO/MFA, logging/SIEM, encryption, backups/DR, privacy/retention).

Interfaces and precedence

  • This policy operates alongside CLD‑ISP (Information Security Policy), CLD‑ACP (Access Control), CLD‑VMP (Threat & Vulnerability) and CLD IR Policy/Plan. Where a client contract or law is stricter, the stricter requirement prevails. Where this policy sets a stricter baseline than a vendor’s standard, this policy prevails unless an approved exception exists.

Residency and data handling

  • Default residency: solutions that store or access personal information must operate in Canada by default (e.g., ca‑central). Approved exceptions require a documented risk assessment and, where personal information is involved, a DPIA with technical and contractual safeguards and an expiry for re‑validation.

  • Data classes assumed: claims records, baggage photos, contact details, delivery addresses, operational metadata.

  • PENDING: FORBIDDEN DATA CATEGORIES — e.g., passport scans, full PAN/SIN, other IDs. Confirm list.

  • PENDING: RETENTION TARGETS — claims photos: [X days/months , claims documents: [Y months/years], customer communications: [Z months/years]; confirm crypto‑shred at end‑of‑life.]

Identity, logging, and monitoring scope

  • Solutions must integrate with CLD identity, enforce MFA for administrative roles and any Restricted data access, and emit security/audit logs sufficient for investigation and correlation.

  • PENDING: IDP/SSO DETAILS — CLD IdP: [Provider ; Protocols required: [OIDC/SAML]; Conditional access/MFA rules: [describe].]

  • PENDING: PROVISIONING MODEL — SCIM required: [Yes/No ; If No, JIT acceptable: [Yes/No].]

  • PENDING: STANDARD ROLES — define RBAC roles and scopes: [Admin , [Operations], [Read‑only], [Support] (or others).]

  • PENDING: SIEM FORWARDING — CLD SIEM forwarding required: [Yes/No ; Ingestion method: [Syslog/API/OpenTelemetry]; Minimum fields: [user, timestamp (UTC), source IP/device, action, target, outcome, correlation ID, isPrivileged].]

  • PENDING: LOG RETENTION — CLD baseline 12 months: [Confirm Yes/adjust to __ months .]

Testing and assurance scope

  • Solutions must support pre‑release security testing (SAST, SCA with SBOM, DAST for web/API), infrastructure/container scans, and annual independent penetration testing with remediation plans.

  • PENDING: SBOM FORMAT — [SPDX/CycloneDX ; Delivery channel: [attach to release ticket/repo path].]

  • PENDING: FAIL GATES — Block release on [Critical/High ; waiver process for [Medium/Low] with ISO approval and POA&M.]

  • PENDING: PENTEST REPORT SHARING — CLD receives [Executive Summary/Full Report ; mandatory PoC for Critical/High: [Yes/No]; fix verification evidence required: [Yes/No].]

Availability and operations scope

  • Vendors must provide encrypted, verified backups, documented recovery procedures, and evidence of restore tests.

  • PENDING: TIERS & TARGETS — Solution tiers and uptime if applicable; RTO/RPO per tier: Tier 1 [RTO/RPO , Tier 2 [RTO/RPO], Tier 3 [RTO/RPO].]

  • PENDING: BACKUP REQUIREMENTS — Immutability/object‑lock for critical data: [Yes/No ; Restore test cadence: [Monthly/Quarterly]; Evidence required: [describe].]

  • PENDING: FILE UPLOAD RULES — Max file size: [__ MB ; Allowed MIME types: [list]; Image metadata (EXIF/GPS) stripping: [Required/Not required]; AV behavior: [Block/Quarantine+Notify].]

  • PENDING: API SECURITY PROFILE — OAuth 2.0 grants allowed: [Auth Code+PKCE, Client Credentials, mTLS ; Access token TTL: [minutes]; Refresh token policy: [enabled/disabled/ days]; Scope naming conventions: [describe].]

Release management scope

  • All production changes must pass CLD gates (design, pre‑production, go‑live, post‑go‑live) with evidence attached.

  • PENDING: CHANGE WINDOWS — Low‑risk notice: [__business days ; High‑risk notice: [__ business days]; Emergency hotfix protocol: [describe].]

  • PENDING: UAT EVIDENCE — Required artifacts for sign‑off: [test cases , [screenshots/recordings], [acceptance checklist], [named approver].]

  • PENDING: RELEASE PACKAGE CONTENTS — confirm: SBOM; SAST/SCA/DAST summaries; change log; deployment + rollback plan; logging schema update (if changed); data‑flow update (if changed); admin/user guides (if changed); acceptance sign‑off.

Subprocessor control

  • Any vendor subprocessor that stores, processes, or accesses CLD data must be disclosed in advance and approved by CLD; vendor must flow down security, privacy, logging, and remediation obligations and provide current SOC 2 Type 2 (or equivalent) reports annually.

  • PENDING: APPROVAL WORKFLOW — CLD approver: [Role/Name ; Notice lead time before onboarding a new subprocessor: [__ days]; Prohibited jurisdictions for storage/access: [list].]

Exceptions

  • Any deviation from this scope or from specific requirements set elsewhere in this policy requires a documented exception with scope, justification, compensating controls, named owner, and expiry, approved by the ISO and Executive Sponsor.

  • PENDING: RESIDENCY EXCEPTION PACK — Required docs: [Risk Assessment , [DPIA if PI involved], [Technical safeguards], [Contract clauses], [Expiry period __ months].]

Checklist of pending inputs (for Vahe)

  • IdP/SSO details; provisioning model; standard roles.

  • SIEM forwarding decision; ingestion method; minimum log fields; retention months.

  • Forbidden data categories; retention targets (photos/docs/comms); EXIF rule.

  • SBOM format and delivery; fail‑gate thresholds; pentest report sharing scope.

  • Tiers with RTO/RPO; backup immutability; restore cadence and evidence.

  • File upload size/types; AV behavior; API OAuth profiles; token TTLs; scope conventions.

  • Change windows/notice; UAT evidence; release package contents.

  • Subprocessor approval workflow; notice lead time; prohibited jurisdictions.

  • Residency exception documentation and expiry (for stuff outside of Canada).