Technical Design Authority (TDA)

The purpose of the TDA

The Technical Design Authority ensures that all technology designs across MHCLG are:

Compliant with the Technology Code of Practice (TCoP)
Aligned with MHCLG technology strategy and standards
Designed securely, sustainably, and following good architectural practice

The TDA approves MHCLG technology strategy, policies, and standards and provides early guidance to project and service teams.

TDA does not:

Approve spend
Provide security assurance
Manage routine change (the Change Advisory Board (CAB) does this)

Roles represented on the TDA panel

Head of Technology (Chair)
Technical Architect
Digital Tools Lead
Cybersecurity Lead
Digital Delivery Lead
Enterprise Data Architect
Cybersecurity Architect
TDA Coordinator
Data Protection
Information Management
CDP / CDO representatives
SAP, DAP, PINS technical architects

When should something go to TDA?

Submit to the TDA when:

Delivering a new system or capability
Making significant changes to existing systems
Introducing new architecture
Creating external exposure or new risks

You can also book a TDA slot to:

Present programme roadmap walkthroughs for large projects (for example, Datamart, SAP, Digital Land)
Ask for guidance about how to approach a new technology project

What to expect from a TDA review

Before the meeting

TDA meets fortnightly on Wednesday afternoons
Book your TDA slot as early as possible (at least 3 weeks before the meeting)
Use the TDA Appointments form to book a slot
Your team must complete the TDA Review and Approval template to provide details of your proposal. This should include:
- system design and architecture diagrams
- technical options considered
- reasons for the preferred solution
- how the solution meets the requirements of TCoP
The document must be submitted to TDAmeeting@communities.gov.uk at least one week before the meeting (by the Thursday before your booked slot) to be circulated to TDA members
Late submissions will lose their slot

During the meeting

You will:

Present a summary slide (PowerPoint)
Talk through key design decisions
Demonstrate technical artefacts (architecture diagrams, workflows, etc.)
Answer questions from:
- Technical Architects
- Cybersecurity leads
- Digital delivery
- Data and information management specialists
- Additional specialists depending on scope

Panels typically probe: risks, security, data, sustainability, compliance, support model, cost clarity.

After the meeting

The outcome will be one of:

Approval
Conditional approval
Non‑approval

You will also receive:

A written list of actions (if applicable) will be issued within 3 working days
Action tracking is managed by PMO

What the panel is looking for

1. A clear reason for submission

Accepted triggers:

New system or capability
Significant change to existing systems
Architectural change
New risks or external exposure

2. Understanding user needs and objectives

Panels expect:

Clear definition of users
Defined user needs
A rationale showing how the design meets those needs

3. A coherent solution overview

Include:

End‑to‑end architecture
Integrations and key components
Data flows
Hosting choice and rationale
Identified constraints and trade‑offs

4. TCoP compliance

Demonstrate compliance with all 13 TCoP points
Weak or missing justification is a common cause of conditional approval

5. Security and privacy evidence

Required:

System risk assessment
Data classifications and handling
Security controls in place
Cyber Security and DPA engagement

6. Risk management

Panels validate:

Risks identified
Mitigations realistic and complete
Residual risks with clear owners

7. Value for money

Panels expect:

Transparent cost model
Efficiency and justification of spend

8. Support and operational readiness

Explain:

Support after go‑live
Monitoring and logging
Release management

9. Adoption and change management

Demonstrate readiness:

Communications
Training
Change impact assessments

Tips for making a good TDA submission

Follow the template exactly

The terms of reference state: “Any submissions that do not follow the template will be rejected and the team stand the chance to lose their slot.”

Provide artefacts early

Submit early:

System design docs
Architecture diagrams
Risk assessments
TCoP responses

Provide a balanced options appraisal

Each option requires:

Description
Benefits
Disadvantages
Risks

Panels strongly dislike single‑option submissions.

Make security a first‑class citizen

Checklist requires evidence of:

Security controls
Cyber team sign‑off
Data Protection sign‑off

Include clear architecture diagrams

Recommended diagram types:

High‑level context
Component views
Data flow diagrams
Deployment architecture

Address future‑proofing and sustainability

Panels often ask: “How will this evolve? Does it avoid vendor lock‑in?”

Articulate dependencies

Clearly document:

Inter‑team dependencies
Required sign‑offs
Dependencies on evolving platforms (e.g., Data 4 Insights)

Explain your support model

Explain:

Monitoring, alerting, logging
Support tiers
Runbooks

Give a verbal summary

Be concise and cover:

Problem
Solution
Risks and mitigations
Security
Cost
“What you need from the TDA”

What “Good” looks like

A high‑quality submission:

Has no empty sections
Shows cross‑department collaboration
Demonstrates TCoP due diligence
Justifies architectural decisions
Includes diagrams
Demonstrates credible risk management
Clearly states approval request or needed guidance

This page was last reviewed on 4 February 2026. It needs to be reviewed again on 4 February 2027 by the page owner #mhclg-way .