Data Platform Assessment Checklist

The short version

A useful data platform assessment answers 3 questions:

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

Review 7 areas: architecture, reliability, data quality, ownership, security, cost, and delivery. Score every answer from evidence. A clean diagram or confident interview isn’t evidence on its own.

This is the structure I use to keep a platform review focused on decisions rather than producing a long inventory of tools.

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 - Repeatable: the team can show the control, owner, and recent evidence.

The total matters less than the pattern. 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 once and reviewed?
• 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. 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.

6. 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.

7. 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.

Turn findings into decisions

Group findings into 4 buckets:

1. Act now: material exposure with an owner and a feasible next action.
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. “Improve governance” isn’t an action. “Assign decision rights for the customer domain and approve one definition of active customer” is.

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

Missing evidence is itself a finding. Record it as unknown. Don’t replace it with confidence.

Primary references

• The Open Group TOGAF Standard - Architecture method, governance, and business requirements
• NIST Cybersecurity Framework 2.0 - Security governance, protection, detection, response, and recovery
• FinOps Framework - Cloud cost allocation, ownership, measurement, and value
• ISO 8000-8 - Data quality measurement and reporting

Last updated: 3 September 2026