Template Storage

Owned by the Template Service.

Purpose

Note

One paragraph describing what this object storage bucket represents and why the Template Service owns it. What kind of files or documents does it hold? For example: “Stores traveler-uploaded passport scans, visa pages, and other travel documents required for NDC fulfillment.”

Data kept

Note

High Level list of the types of objects/documents stored in this object storage bucket (not file-system paths — focus on the business domain):

• Example document type 1 (e.g., passport scans)
• Example document type 2 (e.g., invoice PDFs)
• Example file type 3 (e.g., booking confirmations)

Data sensitivity

Note

Strictly Confidential / Confidential / Internal (select one per Data Classification Policy).

One-line justification. For example: “Stores traveler identity documents (passports, visas) — classified as Strictly Confidential per policy.” Or: “Stores non-confidential file attachments and logs — classified as Internal per policy.”

Retention

Note

How long files are retained and the deletion strategy (if any). Examples:

• TTL-based: “Files are retained for 90 days after order completion, then automatically deleted.”
• Manual process: “Files are archived to cold storage after 1 year; archived files are deleted after 7 years.”
• Indefinite: “Files are retained indefinitely as part of order history, available for retrieval on request.”

Access boundary

Note

By default, only the owning service (Template Service) reads and writes to this bucket. If other services have direct read or write access, list them with justification — these are exceptions to the microservice principle and require explicit approval.

Example:

• “Owner-only access — no exceptions.”
• “Exception: Compliance Service reads archived files in read-only mode for audit purposes (justification: regulatory requirement; access is restricted to compliance staff via IAM).”

Use Cases

Threat Assessments

(TIP)

Each subsection below is one threat assessment, linked to the HLD that triggered it. Add a new subsection when this data store is first introduced, or when an HLD changes its sensitivity classification, retention policy, or access boundary. Not every HLD that references this data store needs an entry — only those that require (re)assessment.

[HLD title](link to HLD) — YYYY-MM-DD

Reason: Data store introduced / Re-evaluated because [reason]

• Sensitivity classification reviewed (<value> — unchanged / updated)
• Retention policy reviewed (unchanged / updated to <X>)
• Access boundary reviewed (unchanged / updated)

Add notes for any unchecked items explaining rationale or planned follow-up.