What Is Data Integrity? a Guide for UK Property Developers

A site looks clean in the first pass. The planning notes seem manageable, the appraisal gives you headroom, and the lender conversation starts well. Then a small detail surfaces. A constraint layer was out of date. A unit mix assumption was copied into the wrong tab. A build cost line was overwritten without anyone noticing. Suddenly the numbers that looked bankable no longer hold.

That's what data integrity looks like in property work. It isn't an IT slogan. It's the difference between a decision you can defend and one that falls apart under scrutiny.

In development and lending, people often talk about risk as if it sits only in planning, cost inflation, sales values, or debt terms. In practice, risk also sits inside the data itself. If your inputs aren't dependable, your outputs won't be either. A polished viability report built on weak source data is still weak.

The easiest way to think about it is construction. If the slab is out, every trade that follows has to compensate for it, and the cost of fixing it rises at each stage. Data works the same way. A bad source record, a missing assumption, an unexplained adjustment, or a version control mistake doesn't stay small for long.

Four business questions usually tell you whether your data has integrity.

• Is it accurate: Does the number or record reflect the actual site, policy position, cost item, or planning constraint?
• Is it complete: Are key fields, evidence, and assumptions present, or are people filling gaps from memory?
• Is it consistent: Do the same figures match across the appraisal, credit paper, planning note, and lender pack?
• Is it traceable: Can you show where the figure came from, who changed it, and why?

If you're trying to sharpen how you monitor problems before they reach the decision stage, DataTeams' guide to data observability is a useful companion read because it focuses on spotting data issues early rather than discovering them after a model has already been circulated.

Introduction

In property finance, what is data integrity becomes a practical question very quickly. It means the information behind your site decision remains sound from first upload to final credit sign off. If that sounds obvious, look at how many deals still rely on disconnected spreadsheets, copied planning notes, manual map checks, and assumptions passed between teams in email.

That setup creates silent risk. One person updates the flood note but not the appraisal. Another adjusts tenure mix without updating revenue assumptions. A lender receives a pack where the conclusion is recent but the evidence underneath it isn't. Nobody intended to create bad data. The workflow created it.

The four pillars in plain business terms

A useful working definition starts with four pillars.

Pillar	What it means in practice	Property example
Accuracy	The record reflects reality	A site area, policy threshold, or unit count is correct
Completeness	Nothing essential is missing	Build cost assumptions, constraints, and planning notes are all present
Consistency	The same fact matches everywhere it appears	GDV in the appraisal matches the figure in the lender memo
Traceability	You can follow the history of the number	You know who changed an input and when

Teams often think they're strong on this until they test a live deal. Then they find that the final verdict is only loosely tied to the underlying source material.

Practical rule: If a number changes your land bid, debt requirement, or profit threshold, it needs a visible source and a visible history.

Why this matters in property finance

Property viability is unforgiving. Small changes in assumptions can shift a scheme from acceptable to marginal. That's why data integrity belongs with underwriting discipline, not in a side conversation with IT.

A lender doesn't just back a forecast. They back the credibility of the process that produced it. A developer doesn't just buy land. They buy the consequences of every assumption inside the model. If the data trail is weak, confidence drops fast.

What Data Integrity Means for Your Business

The formal UK definition matters because it removes any ambiguity. In the UK regulatory context, data integrity is defined as the degree to which data are complete, consistent, accurate, trustworthy, and reliable throughout the entire lifecycle, and that standard sits alongside the ALCOA+ principles under the MHRA GxP data integrity guidance and the UK GDPR integrity and confidentiality principle.

That may sound like language built for life sciences or compliance teams, but the business lesson applies directly to property. If your appraisal data isn't complete, consistent, accurate, trustworthy, and reliable through the full workflow, your decision quality is compromised. It doesn't matter how neat the final PDF looks.

How the foundation shows up in daily work

The foundation analogy is the right one. You rarely see data integrity in isolation. You see its effects.

A land manager sees it when a site note says one thing and the appraisal assumes another. An analyst sees it when one spreadsheet version carries a cost change that never made it into the credit pack. A lender sees it when the peak funding output looks fine, but no one can explain where a planning adjustment came from.

Here's how the four core business pillars usually appear in real workflows.

• Accuracy matters when entering site area, unit numbers, sales rates, or abnormal costs. If one figure is wrong, every downstream ratio based on it is wrong too.
• Completeness matters when a record lacks a key policy constraint, supporting evidence, or the date an assumption was sourced. Missing fields force teams to guess.
• Consistency matters when planning intelligence, appraisal outputs, and underwriting commentary should align but don't.
• Traceability matters when someone asks who changed a density assumption, what the prior value was, and why the update happened.

Why business leaders should care

Most property teams don't lose confidence because of one dramatic systems failure. They lose it because small contradictions keep appearing. Those contradictions slow bids, invite lender questions, and create rework across planning, finance, and credit.

Poor data integrity doesn't just create bad reports. It creates hesitation. And hesitation costs deals.

When people ask what data integrity means for a business, the answer is simple. It means your people can rely on the information they're using when the decision is expensive, time sensitive, and hard to reverse.

Common Ways Data Integrity Fails in Property Deals

The biggest failures are usually mundane. They don't arrive as a cyber attack or a dramatic system outage. They show up as routine handling errors inside busy teams.

The human element is a major part of the problem. The UK Information Commissioner's Office reports that approximately 40% of reported breaches involve human error, including sending data to the wrong recipient or failing to secure editable files, in its data security incident trends. In property terms, that same pattern appears when staff copy figures into live appraisal models, circulate editable packs, or overwrite assumptions without preserving a record.

Three failure points that hit deals hardest

The first is manual entry into appraisal spreadsheets. This sounds basic because it is basic. A mistyped land cost, an incorrect unit count, or a cost line entered in the wrong place can distort the whole result. The problem isn't only the original mistake. It's that spreadsheets often make the mistake hard to detect.

The second is copying data between documents. Planning reports, consultant notes, valuation comments, and appraisals often live in separate places. Every transfer creates a chance for mismatch. A flood designation might be updated in one note but not carried into the financial model. A heritage issue might appear in diligence material but never make it into assumptions on programme or scheme yield.

The third is reliance on stale third party inputs. If your team uses planning intelligence, flood records, or heritage data that's no longer current, the model can still look coherent while being wrong in substance.

For a broader security and systems view, understanding integrity vulnerabilities is useful because it shows how software and data integrity failures often come from change control and verification gaps rather than dramatic external attacks.

What works and what doesn't

What doesn't work is telling analysts to be more careful while leaving the same brittle workflow in place. What does work is splitting the response into system controls and team rules.

Technical guardrails

• Field validation: Systems should reject impossible values and flag missing required inputs before a model runs.
• Permissions: Not everyone should be able to alter commercial assumptions or planning conclusions.
• Audit history: Every meaningful change should leave a record.

Procedural rules

• Second review for material inputs: Critical assumptions need another pair of eyes.
• Source capture at entry: Don't let people add assumptions without recording where they came from.
• Version discipline: One approved record should feed the deal, not a chain of conflicting files.

A practical comparison of controlled workflows versus spreadsheet led processes can be seen in development appraisal software approaches, especially where repeatability and auditability matter.

A short visual explanation helps here.

Building a Framework for Trustworthy Data

A viability assessment is only as credible as the weakest input inside it. That's the old garbage in, garbage out problem, and in property it's expensive because teams often discover the flaw after they've priced land, briefed debt providers, or committed management time.

The answer isn't endless checking by hand. It's a framework that makes weak data harder to enter, easier to detect, and simpler to investigate.

Start with technical guardrails

The best systems prevent bad data at the point of entry. According to techUK's discussion of data sovereignty and technical controls, data integrity is enforced through guardrails such as domain constraints and validation frameworks that check data types and ranges before errors propagate. The same source also notes the use of hashes and checksums for critical records to validate data against unauthorised drift.

That matters in property models more than people think. If a system allows a negative build cost, an impossible date sequence, or a missing policy input to pass into a live appraisal, it's already failed.

Use controls that do the following.

• Reject invalid values: Cost fields should accept plausible formats and ranges only.
• Quarantine incomplete records: If the site record lacks key constraints or source evidence, it shouldn't progress as decision ready.
• Preserve integrity in transmission: If reports, exports, or build outputs are shared, they need controls that show whether they've been altered.

Then tighten the human process

Technology won't fix a weak operating rhythm. Teams still need rules.

Control area	Weak approach	Strong approach
Data entry	One person keys critical assumptions unchecked	Material inputs get reviewed by a second person
Templates	Every analyst uses a different workbook	Standard templates define required fields and naming
Change tracking	Updates happen silently	Changes are logged with date, owner, and reason
Evidence	Assumptions are explained verbally	Each assumption carries a source and timestamp

Working rule: If a lender or investment committee asks “where did that number come from?”, the answer shouldn't depend on who happens to be in the room.

For approval stages, contract changes, and sign offs, a solid understanding of eSignature audit trails helps because it shows what a defensible record of action should look like when people approve, amend, or complete documentation.

Why migration matters more than teams admit

A lot of integrity loss happens during transition. Data moves from legacy spreadsheets, old appraisal templates, email chains, and consultant reports into a new working model. If that migration is rushed, the new system directly inherits old contradictions.

That's why disciplined data migration into a controlled workflow matters. Migration isn't admin. It's where a team decides which fields are authoritative, which assumptions need evidence, and which historic records can't be trusted without review.

The test is blunt. If your current process allows silent changes, missing sources, or multiple conflicting versions, then your framework is too weak for lending and viability work.

How Data Integrity Directly Impacts UK Property Viability

Moving beyond theory, in UK property, poor data integrity directly distorts viability. It changes the numbers people use to price land, structure debt, and decide whether a scheme can survive planning and finance scrutiny.

The challenge is bigger than many teams assume. In the UK, 68% of development proposals face viability challenges due to inconsistent data inputs from sources such as Environment Agency flood maps and Heritage England registers, and the cited analysis on data integrity challenges notes that these failures make GDV and profit on cost calculations unreliable. The same source states that drift in peak funding indicators can lead to lender rejection.

How one bad input travels through the model

Take a straightforward example. A team assumes a site can support a higher unit count because a planning constraint was missed or interpreted from an outdated record. That single assumption then flows through the entire appraisal.

First, GDV rises because the scheme appears to deliver more saleable output.

Second, cost assumptions shift because build cost, fees, finance, and programme are all tied to the assumed form of development.

Third, profit on cost and residual land value move. The land offer starts to look stronger than it should.

Fourth, peak funding changes. The debt request may appear manageable when in truth the actual scheme would strain the capital stack.

When someone later corrects the planning position, the scheme can collapse. Not because the market moved, but because the original data didn't hold.

Why lenders focus on the inputs, not just the answer

Lenders and credit teams have learned this the hard way. A tidy headline profit figure doesn't mean much if the underlying assumptions can't be traced and defended.

They want to know:

• Where planning assumptions came from
• Whether constraints were current when the model ran
• Who changed commercial inputs and when
• Whether scenario outputs were produced from one controlled dataset

That scrutiny is rational. A lender isn't funding a spreadsheet result. They're funding the chain of evidence behind it.

If the source data is weak, the model isn't conservative or aggressive. It's simply unreliable.

Immediate steps to reduce viability risk

Teams don't need a full systems overhaul before improving this. They can start by tightening a few points in the chain.

1. Lock the source pack before modelling
   Don't run viability until planning, constraints, and key commercial assumptions are dated and confirmed.

2. Separate source facts from judgement calls
   Flood status, heritage designation, and measured site data should not sit in the same category as commercial assumptions or planning strategy opinions.

3. Track every material change to unit count, GDV, build cost, and funding outputs
   If those numbers move, there should be a visible explanation.

4. Run scenario testing from the same approved record
   Low, base, and high cases are useful only when they derive from one controlled source set.

5. Make the lender pack evidence led
   Don't just export outputs. Show where the critical assumptions originated.

Viability work always involves judgement. Data integrity doesn't remove judgement. It makes sure judgement is being applied to dependable information instead of contaminated inputs.

Practical Steps for Developers and Lenders

At deal level, improving data integrity isn't about building a grand governance manual. It's about making each handoff cleaner. Site sourcing, due diligence, modelling, underwriting, and reporting all need a tighter chain of evidence.

The commercial reason is obvious. In UK plan making, a return of 15–20% of GDV is benchmarked as a suitable developer return to establish viability under national planning guidance on viability. When the benchmark is that tight, the integrity of the underlying inputs matters because even modest errors can change whether a scheme appears to clear the threshold.

A deal stage checklist that people will actually use

At site sourcing

• Confirm source hierarchy: Decide which dataset or document is authoritative for each key field.
• Date every planning and constraints input: If nobody can see when it was sourced, it shouldn't guide a bid.
• Stop free text where structured fields are possible: Site area, access status, flood designation, and policy notes should be captured consistently.

During due diligence

• Cross check planning intelligence against the commercial model: Don't let legal, planning, and finance work in separate fact worlds.
• Flag unresolved issues clearly: A questionable assumption shouldn't be hidden inside a note.
• Use one secure environment for live records: Security and access discipline matter, especially where sensitive financial data is shared. A practical benchmark for that is a controlled environment with permissions and audit expectations such as those outlined in Domus security information.

When running the appraisal

• Validate before calculation: No model should run with missing required fields.
• Lock core assumptions once approved: If someone changes tenure split, build cost, or unit count, the record should show it.
• Keep scenarios connected to one source set: Base, low, and high cases should differ by explicit assumptions, not by hidden version drift.

What lenders should ask for

Developers often focus on making the output persuasive. Lenders should focus on making the input defensible.

A good evidence pack should include:

Area	What to ask for
Planning	Source notes, dates, and any unresolved policy interpretation
Constraints	Current mapping or register evidence for material issues
Financial assumptions	Dated rationale for GDV, costs, and programme
Change history	Record of major assumption changes before sign off

Credit view: A fast answer isn't the same as a reliable answer. Ask for the assumption trail, not just the headline margin.

The teams that handle this well usually share one habit. They stop treating data checks as an afterthought before approval and start treating them as part of the deal process itself.

Your Data Integrity Checklist for Real Estate Workflows

Use this as a working check before you trust a site appraisal, submit a lender pack, or sign off a viability view.

Site sourcing and due diligence

• Are the core site facts sourced and dated
• Have planning constraints and statutory designations been checked against current records
• Is there one agreed record for site area, access, and development assumptions
• Are unresolved issues visible, rather than buried in commentary

Financial modelling and appraisal

• Are all key assumptions recorded with their origin
• Does the model reject missing or invalid inputs
• Do GDV, cost, and funding figures match across outputs
• Can someone else follow the logic without asking the original analyst

Underwriting and credit risk

• Can the team explain who changed material assumptions and why
• Do scenario outputs come from one controlled source set
• Is the viability conclusion supported by evidence, not only by a summary page
• Would the pack survive a detailed lender challenge

Stakeholder reporting

• Does the reported result match the latest approved dataset
• Are exports protected against silent changes
• Can non technical stakeholders see what is fact and what is judgement
• Is there a reliable record of review and approval

If you can't answer those questions cleanly, don't trust the output yet.

---

Domus helps UK property teams bring planning intelligence, constraints mapping, appraisal, viability modelling, and finance outputs into one decision ready workflow. If you want fewer spreadsheet gaps, cleaner auditability, and faster site level decisions, explore Domus.