Data Platform Assessment Checklist

The short version

A useful data platform assessment answers:

1. What is solid enough to keep?
2. What can fail or block growth?
3. Which actions change that risk first?

The areas below cover architecture, reliability, data quality, ownership, scheduling, security, cost, and delivery. Score every answer from evidence. A clean diagram or a confident interview isn’t evidence on its own.

This is the structure I use in a platform review. It keeps the review on the decisions the client has to make.

How to score the assessment

Use a simple score for each checkpoint:

• 0 - Unknown or absent: nobody can show how it works, or the control doesn’t exist.
• 1 - Partial: the practice exists for some systems or depends on one person.
• 2 - Established: the team can show the control, its owner, and recent evidence that it ran. Whether it runs consistently is a separate question, so note how often the evidence appears.

Use the pattern of scores to decide what to look at first. A low score in security or recovery can outweigh several well-run areas. Record evidence and consequences beside every number.

1. Architecture

• Can the team draw the current data flow from source to consumer?
• Does the diagram match deployed systems and repositories?
• Are system boundaries and responsibilities explicit?
• Are decisions recorded with their context and trade-offs?
• Can the team explain why each major platform component exists?
• Are batch, streaming, warehouse, lake, and lakehouse choices tied to actual requirements?
• Which component would be hardest to replace, and why?

Evidence: current architecture diagram, system inventory, decision records, repository map, integration list, and vendor contracts.

Warning signs: a target-state diagram presented as current state, several tools doing the same job, undocumented point-to-point integrations, or a platform choice nobody can explain.

2. Reliability and recovery

• Which pipelines and datasets are critical to an operational or financial process?
• Are freshness, completion, and failure states monitored?
• Does every critical failure have an owner and escalation path?
• When was the last recovery test?
• Can failed work restart safely?
• Are upstream and downstream dependencies visible?
• Does the incident record show recurring causes?

Evidence: service objectives, alerts, incident history, runbooks, orchestration logs, recovery tests, and dependency graphs.

Warning signs: alerts without owners, manual reruns known by one engineer, successful jobs that publish incomplete data, or backup policies nobody has tested.

3. Data quality and trust

• Which datasets or metrics drive decisions that matter?
• What does acceptable quality mean for each use?
• Where are validity, completeness, freshness, and reconciliation checked?
• Are checks placed near the source of the failure?
• Can consumers see known limitations?
• Who decides whether a failed check blocks publication?
• Are recurring issues traced to a root cause?

Evidence: quality rules, test results, reconciliation reports, issue history, data contracts, metric definitions, and consumer-facing status information.

Warning signs: one quality score for every use case, tests added only after incidents, a dashboard nobody can reconcile to the source, or analysts repairing the same data manually.

4. Ownership and governance

• Does each critical data product have a business and technical owner?
• Can those owners decide definition, access, quality, and change?
• Are important business terms defined, scoped, and owned? Customer and revenue often have several valid definitions; the problem is when nobody says which one a report uses.
• Is access granted through a repeatable process?
• Are retention and deletion decisions owned?
• How are schema and semantic changes communicated?
• Where does a disagreement go when teams can’t resolve it?

Evidence: ownership register, decision rights, glossary, access workflow, retention policy, change process, and escalation path.

Warning signs: the data team owns every quality problem, several definitions of customer or revenue, approvals living in chat history, or governance meetings with no decision authority.

5. Scheduling and orchestration

• Where can a job be scheduled? List every place: the orchestrator, the ingestion tool’s own schedules, dbt Cloud jobs, a cloud function on a timer, and the crontab on a VM someone set up during a migration.
• For each scheduler, what runs there?
• Does a failure there alert a channel somebody reads?
• Who owns that scheduler, by name?
• When a job hasn’t run by 6am, is it obvious which console to open?
• Are schedules and cross-tool dependencies visible somewhere, or reconstructed from memory?
• Does anything critical run on a machine nobody would know how to rebuild?

Evidence: scheduler inventory, the job list per scheduler, alert routing, on-call rota, a dependency or lineage view, and the crontabs on long-lived VMs.

Warning signs: a 6am failure that could live in four consoles, a scheduler with no alert and no owner, jobs triggered under a personal account, or a schedule only one engineer can explain.

6. Security and compliance

• Is access based on role and least privilege?
• Are human and service identities separated?
• Are secrets managed outside code and configuration files?
• Can the team show who accessed sensitive data?
• Are encryption, retention, residency, and deletion requirements documented?
• Are third-party transfers known?
• Is incident handling connected to legal and regulatory obligations?

Evidence: identity and access configuration, audit logs, data classification, risk assessment, processor list, retention schedule, and incident procedure.

Warning signs: shared credentials, broad production access, sensitive fields copied into development, no access review, or compliance evidence assembled only before an audit.

7. Cost and commercial constraints

• Can platform cost be attributed to a workload, product, team, or client?
• Which resources run without an active owner?
• Are compute schedules and auto-suspend settings intentional?
• Do retention and storage tiers match access patterns?
• Which queries or jobs drive variable cost?
• Are commitment discounts based on stable usage evidence?
• What are the contract, egress, and exit constraints of major vendors?

Evidence: invoices, cost-allocation tags, workload cost reports, utilization, retention settings, commitment contracts, and vendor terms.

Warning signs: one undivided cloud bill, commitments bought before usage stabilizes, copies with no named purpose, or a migration justified only by an estimated saving.

The four-line dataset SLA

Freshness, ownership, and cost each sit in a different area above, which is how they get lost. For the datasets that matter, write four lines per dataset:

• Freshness: how stale can this get before somebody makes a wrong call?
• Lateness: how long after its target time can this arrive before it matters to the people downstream?
• Owner: the name of a person who decides. A team name doesn’t count.
• Cost ceiling: what this dataset is allowed to cost per month.

The ceiling is the line people push back on, and it’s still worth writing down. A number you can be wrong about beats no number.

Start with your most expensive table. If the owner line is blank, that’s the finding.

8. Delivery and team capability

• Who can change each critical component safely?
• How is work tested, reviewed, deployed, and rolled back?
• Does the roadmap connect platform work to business outcomes?
• How much work is planned versus interrupt-driven?
• Where does the team depend on one person?
• Can new engineers find the code, decisions, and operating procedures?
• Which capability should be internal before an external specialist leaves?

Evidence: roadmap, backlog, deployment history, review rules, onboarding material, ownership map, skills view, and incident data.

Warning signs: a roadmap made entirely of tools, one engineer approving every change, repeated emergency work, or external people owning knowledge the team needs to operate.

Build-to-run handoff

New work usually starts in one team and ends up operated by another: a prototype from a product squad, a model from a data scientist, a pipeline from an external partner.

• Who operates this once it’s live, and did they see it before the handover?
• Was the operating team’s definition of done agreed up front: alerting, backfill, an owner, a rollback?
• Did the build team write the first runbook, and has the operating team corrected it from a real run?
• Has the operating team run a failure and a recovery themselves?
• Is support responsibility written down, including when the build team’s involvement ends?
• Who signs the handover off?

Evidence: handover records, operational acceptance criteria, runbooks with authors, access grants for the operating team, and the first weeks of incident history after a handover.

Warning signs: work sitting in a “productionising” ticket for a quarter, the original builder still on call months later, or an operating team that first sees the system when it breaks.

Turn findings into decisions

Group the findings:

1. Act now: a serious risk that has an owner and an action the team can take now.
2. Plan: important work that depends on another decision or capability.
3. Monitor: a known risk with an explicit trigger for action.
4. Accept: a conscious trade-off whose consequence the owner understands.

Every action needs an owner, evidence of completion, and a review date. Write it so the owner can tell when it’s done: “assign decision rights for the customer domain and approve one definition of active customer” can be finished, while “improve governance” can’t.

The minimum evidence pack

• Current architecture and data-flow diagrams
• Source, integration, and platform inventory
• Repositories and deployment process
• Pipeline and job history
• Incident and support records
• Data quality checks and known issues
• Access model and audit logs
• Recent cloud and vendor invoices
• Ownership and glossary material
• Current roadmap and team structure

If evidence is missing, record the checkpoint as unknown. That is a finding in itself.

Primary references

• The Open Group TOGAF Standard - Architecture method, governance, and business requirements
• NIST Cybersecurity Framework 2.0 - Security governance, identification, protection, detection, response, and recovery
• FinOps Framework - Cloud cost allocation, ownership, measurement, and value
• ISO 8000-8 - Concepts and prerequisites for measuring information and data quality

Last updated: 3 September 2026