Back to path
Draft complete12 minutes

Security, privacy, records, and data authorities

Data classification and placement

Connect data purpose and classification to provider placement, access, lifecycle, review, and application evidence.

The short answer

Classify each data category using the controlled DOA baseline, then evaluate purpose, owner, users, flows, provider placement, access, retention, sharing, recovery, and risk. A classification label informs the review, but it does not by itself approve an application or provider placement.

01

Controlled baseline

Use four labels, then preserve uncertainty

The signed DOA policy supplies Public, Internal, Confidential, and Restricted classifications. Internal is the default for new or unlabeled DOA data in the controlled draft workflow. When classification is uncertain, use the higher reasonable level until the Data Owner or governance authority confirms it.

Public data still needs an accountable owner and authorized-release basis. Confidential and Restricted uses require deeper or separate review. The repository does not contain the controlling City DLP or classification standard with detailed handling rules, so do not invent those rules from an unpublished draft.

DOA classification baselineThe label informs handling and routing. It does not grant platform placement by itself.
01PublicConfirm authorized release, owner, and publication basis.
02InternalDefault for new or unlabeled DOA data; complete application and technical review.
03ConfidentialPerform application-specific control review across the full data lifecycle.
04RestrictedRoute to separate review and any required exception or authority decision.
02

Placement

Follow the data through the whole system

Inventory data entering, created by, stored in, transformed by, transmitted from, exported from, and deleted by the application. Record sources, recipients, providers, regions, identities, integrations, APIs, notifications, backups, and downstream uses.

Provider capability does not prove that a configuration meets the data requirement. A placement decision needs a named purpose and owners, a matching architecture, implementable controls, triggered reviews, and evidence at the appropriate gate.

  • Name the authoritative source and whether the application creates a new system of record.
  • Map every role, privileged path, external user, anonymous exposure, export, and recipient.
  • Record retention-series mapping, legal-hold handling, deletion, return, export, and verified disposal.
From data idea to production placementMissing material detail results in DEFER PENDING EVIDENCE in the draft procedure.
01InventoryData, purpose, owner, source, transformations, flows, users, and lifecycle
02ClassifyApply the DOA baseline and record uncertainty and validating authority
03RouteTrigger Data, Cyber, Operations, ARB, API, AI, sharing, or exception review
04VerifyTest placement, access, logging, retention, recovery, and conditions before production
03

Decision routes

Let the use case trigger the right authority

External sharing, APIs, AI use, Confidential or Restricted data, external users, public exposure, privileged integrations, operational dependency, provider deviations, and unusual notification patterns can change the review route. Technology authorization does not replace these decisions.

The Aviation retention schedule is the controlling centralized schedule according to the captured CDO clarification. If a record does not match a series, Data Management or Data Governance coordinates with the applicable policy owner to amend the governing source. Do not invent a retention period.

  • Reassess after a material change to data, purpose, source, recipient, provider, region, user population, integration, retention, sharing, or exposure.
  • Keep decision authority, concurrence, conditions, expiration, review date, and evidence paths with the record.
  • Do not introduce production data while required classification, placement, or exception evidence remains unresolved.

The Ember lens

The Ember baseline review excludes or separately routes high-risk uses such as HR and payroll data, personal financial data, security or life-safety workflows, airport operational dependency, and deviations from the reference architecture. The replacement classification and placement SOP is still APPROVAL NEEDED. Its approval, official form, system of record, exception authority, implementation RACI, and first completed application record are MISSING.

Responsibility remains

The Data Owner authorizes purpose and remains accountable for the data. The Data Steward maintains inventory and classification detail. The Data Custodian identifies technical controls and evidence. Engineering evaluates whether Ember can enforce the requirements. Data Governance, Cyber, Operations, and ARB record reviews when triggered. The draft role model does not create authority or approve placement.

Apply it

Route a new case-management dataset

A team proposes an Ember workflow containing employee contact details, internal case notes, file attachments, and email notifications to an approved external partner. The owner calls all of it 'Internal.'

  1. 01Separate the data into categories and identify the owner and permitted purpose for each.
  2. 02Mark classification uncertainties and state how they must be resolved without inventing a rule.
  3. 03Draw the data flow across users, Render, Supabase, SendGrid, exports, backups, and the external recipient.
  4. 04List the review triggers, lifecycle questions, and evidence required before production placement.

Check your understanding

Make the ideas usable

2 questions
01What does an Internal classification prove about Ember placement?
02What should happen when an application record does not match the controlling retention schedule?

Source trace

Reviewable by design

Content owner: Wesley Almeida
Last reviewed: 2026-08-18

  • Ember application data classification and placement SOP draft05-projects/vibe-coding-platform/resources/standards/
  • CDO data policy clarification05-projects/vibe-coding-platform/resources/standards/cdo-data-policy-clarification-2026-08-11.md
  • Ember platform project status and data guardrails05-projects/vibe-coding-platform/PROJECT.md
  • Ember platform architecture and data classification boundary05-projects/vibe-coding-platform/resources/diagrams/platform-reference-architecture-and-data-flow-draft-2026-07-13.md