Skip to main content

Data Journalism Methodology Pack

Five templates for UK data journalists: methodology note, data source log, data cleaning log, reproducibility checklist, and ethics review. Aligned with the ONS Code of Practice and ICO data ethics guidance.

Last reviewed: Next review due:

What’s in this pack

Five templates covering methodology, sourcing, cleaning, reproducibility, and ethics.

Methodology Note

Public-facing note covering data, analysis steps, limitations, and findings.

Data Source Log

URL, date, hash, licence, and coverage for every dataset used.

Data Cleaning Log

Step-by-step record of every transformation, exclusion, and assumption.

Reproducibility Checklist

Confirms raw data, code, steps, and key figures can be independently verified.

Ethics Review

Personal data, harm assessment, accuracy, conflicts of interest, and sign-off.

Template 1: Methodology Note

Publish this alongside your data story, or link to it. Describes what data you used and how you analysed it.

METHODOLOGY NOTE

Article title: [TITLE]
Publication: [PUBLICATION]
Author(s): [NAMES]
Date of publication: [DATE]
Date of methodology note: [DATE]

1. WHAT THIS STORY IS ABOUT
[One to two sentence plain-language summary of the data story.]

2. WHAT DATA WAS USED
Primary dataset(s):
— [Dataset name], published by [Organisation], accessed [DATE], URL: [URL]
— [Dataset name], published by [Organisation], accessed [DATE], URL: [URL]

Supporting data sources:
— [Source, date, URL]

3. HOW THE DATA WAS ANALYSED
[Describe step by step:]
(a) Data was downloaded from [SOURCE] on [DATE] and saved in its original format ([CSV / Excel / JSON — specify]).
(b) [Describe any filtering: e.g. rows were filtered to include only [CRITERIA].]
(c) [Describe any calculations: e.g. year-on-year change was calculated as [(current year value - previous year value) / previous year value] × 100.]
(d) [Describe any merging: e.g. datasets were joined on [FIELD].]
(e) [Describe any exclusions and why.]

4. KEY FINDINGS
[List the main data findings as numbered statements:]
1. [Finding — with the precise figure and the base it is drawn from]
2. [Finding]

5. LIMITATIONS
[Be honest about what the data cannot tell you:]
— [Limitation 1]
— [Limitation 2]

6. WHAT WE ASKED
[Describe what you put to relevant organisations for comment and what responses you received.]

7. CODE AND DATA
[If code was used: link to GitHub or equivalent repository.] / [If no code: state analysis method used, e.g. Excel pivot tables.]

Sources: ONS Code of Practice for Statistics (ons.gov.uk/methodology), OSR (osr.statisticsauthority.gov.uk)

Template 2: Data Source Log

An internal record. Complete one entry for every dataset used, recording the hash before any processing.

DATA SOURCE LOG

Project / article: [TITLE]
Analyst: [YOUR NAME]
Date started: [DATE]

---

SOURCE ENTRY

Source #: [e.g. 001]
Dataset name: [FULL NAME OF DATASET]
Publisher / originator: [ORGANISATION]
URL: [FULL URL — include query string if applicable]
Date accessed: [DATE]
File format: [CSV / Excel / JSON / PDF / API / Other]
File size: [SIZE]
SHA-256 hash of raw file: [HASH — generate with certUtil -hashfile filename SHA256 (Windows) or shasum -a 256 filename (Mac/Linux)]

Licence / terms of use:
[ ] Open Government Licence v3.0 (OGL) — free to use and adapt with attribution
[ ] Creative Commons [specify variant]
[ ] Proprietary / subscription — licence held: [REF]
[ ] No licence stated — note any restrictions: [DESCRIBE]
Attribution required: [ ] Yes — exact wording: [TEXT]  [ ] No

Coverage:
Geography: [e.g. England and Wales / UK / Greater London]
Time period: [e.g. Financial year 2023-24 / Q1 2025]
Population covered: [e.g. All registered GP practices in England]

Known limitations of this source:
[DESCRIBE — e.g. self-reported; potential undercount; revised annually]

Notes:
[ANY OTHER RELEVANT INFORMATION]

---

[Repeat SOURCE ENTRY block for each dataset]

---

SUMMARY OF SOURCES USED IN FINAL ARTICLE

Source # | Dataset name | Publisher | Date accessed | Used for
---------|-------------|-----------|--------------|--------
001 | [NAME] | [ORG] | [DATE] | [USE]

Template 3: Data Cleaning Log

Record every transformation as you make it. Do not reconstruct retrospectively.

DATA CLEANING LOG

Project / article: [TITLE]
Analyst: [YOUR NAME]
Date: [DATE]
Source dataset(s): [NAMES]
Tool used: [Excel / Google Sheets / Python / R / SQL / OpenRefine — specify]

PURPOSE
This log records every transformation applied to the raw data. It enables another analyst to reproduce the analysis from the raw source.

---

STEP-BY-STEP LOG

Step # | Action | Reason | Input | Output | Performed by | Date
-------|--------|--------|-------|--------|-------------|-----
001 | [e.g. Removed 14 rows where [FIELD] was blank] | [Blank values in this field indicate records excluded from scope] | [Raw file v1] | [Cleaned file v1] | [NAME] | [DATE]
002 | [e.g. Standardised date format in column [X] from DD/MM/YYYY to YYYY-MM-DD] | [Consistency required for sorting and calculation] | [Cleaned file v1] | [Cleaned file v2] | [NAME] | [DATE]
003 | [e.g. Merged [COLUMN A] and [COLUMN B] into new column [COLUMN C]] | [Single consistent reference field required for join with dataset 002] | [Cleaned file v2] | [Cleaned file v3] | [NAME] | [DATE]

---

EXCLUSIONS AND ASSUMPTIONS

What was excluded | Reason | Row count affected
-----------------|--------|-------------------
[e.g. Rows where [FIELD] = "Not applicable"] | [Out of scope for analysis] | [NUMBER]

Missing values handling:
[Describe how nulls / blanks were treated: e.g. treated as zero / excluded / flagged]

Assumptions made:
[List any assumptions — e.g. "where [FIELD] was recorded as [VALUE], this was interpreted as [MEANING] based on the data dictionary at [URL]"]

---

FINAL DATASET
File name: [FILENAME]
Row count: [NUMBER]
SHA-256 hash: [HASH]
Date finalised: [DATE]

Template 4: Reproducibility Checklist

Complete before submitting any data-driven piece. Have an editor or second analyst run the spot-check.

REPRODUCIBILITY CHECKLIST

Project / article: [TITLE]
Analyst: [YOUR NAME]
Date of check: [DATE]
Reviewer (if different): [NAME]

PURPOSE: Confirm that this analysis can be reproduced by another analyst starting from the raw data.

RAW DATA
[ ] All raw source files are saved and accessible at: [LOCATION]
[ ] SHA-256 hashes recorded for all raw files (see Data Source Log)
[ ] Source URLs and access dates recorded
[ ] Licence terms confirmed

ANALYSIS STEPS
[ ] Data Cleaning Log is complete and covers every transformation
[ ] All exclusions and assumptions are documented
[ ] If code was used: code is saved at [LOCATION / REPOSITORY URL]
[ ] If code was used: dependencies and versions documented (e.g. requirements.txt / sessionInfo())
[ ] If no code: step-by-step process documented in sufficient detail for manual reproduction

KEY FIGURES
[ ] Every key figure cited in the article is traceable to a specific row/calculation in the analysis
[ ] Spot-check: [NUMBER] key figures independently recalculated by [REVIEWER NAME] on [DATE]

OUTPUTS
[ ] Final cleaned dataset saved at: [LOCATION]
[ ] Methodology note written and approved for publication
[ ] Any charts or visualisations include source and notes on data

SIGN-OFF
Analyst: _______________________ Date: ___________
Editor / data editor: _______________________ Date: ___________

Sources: ONS Code of Practice for Statistics, OSR (osr.statisticsauthority.gov.uk)

Template 5: Ethics Review

Required for any analysis involving personal data or potential harm to identifiable individuals or groups.

DATA JOURNALISM ETHICS REVIEW

Project / article: [TITLE]
Analyst / journalist: [YOUR NAME]
Editor: [NAME]
Date: [DATE]

1. PERSONAL DATA
Does this analysis involve personal data (data that identifies or could identify individuals)?
[ ] No — proceed to Section 3
[ ] Yes — complete Section 2

2. PERSONAL DATA ASSESSMENT (if yes above)
What personal data is involved: [DESCRIBE]
Legal basis for processing (UK GDPR / DPA 2018):
[ ] Journalism / special purposes exemption (DPA 2018 Schedule 2, Part 5) — public interest confirmed: [DESCRIBE]
[ ] Other basis: [SPECIFY]

Minimisation: Is only the minimum necessary personal data being used?
[ ] Yes  [ ] No — explain: [REASON]

Storage and security: How is personal data being stored and who has access?
[DESCRIBE — e.g. encrypted local drive, access restricted to [NAMES]]

Retention: When will the personal data be deleted?
[DATE OR EVENT — e.g. on publication; after [PERIOD]]

3. HARM ASSESSMENT
Could publication of this analysis cause harm to identifiable individuals or communities?
[ ] No  [ ] Possible — describe: [DESCRIBE]
Mitigation: [HOW HARM IS REDUCED]

4. ACCURACY AND FAIRNESS
Are the findings presented in a way that is proportionate and not misleading?
[ ] Yes  [ ] No — explain: [EXPLAIN]
Have relevant organisations been given the opportunity to comment on the key findings?
[ ] Yes — response received: [SUMMARY]  [ ] No response by deadline  [ ] Not applicable

5. CONFLICTS OF INTEREST
Does the analyst or journalist have any interest in the subject that could affect objectivity?
[ ] No  [ ] Yes — disclosed to editor: [DATE]

6. SIGN-OFF
Analysis cleared for publication:

Analyst: _______________________ Date: ___________
Editor: _______________________ Date: ___________

Sources: ONS Code of Practice (ons.gov.uk/methodology), ICO Data Ethics (ico.org.uk/for-organisations/data-ethics), OSR (osr.statisticsauthority.gov.uk)

Primary sources

Frequently asked questions

What is the ONS Code of Practice for Statistics and why does it matter to data journalists?
The UK Statistics Authority's Code of Practice for Statistics sets standards for the production and dissemination of official statistics. It has three pillars: Trustworthiness, Quality, and Value. For data journalists, it matters because: (1) it tells you how to interpret official statistics correctly — including which statistics are designated as National Statistics; (2) it provides a standard against which to evaluate data quality; and (3) it underpins the Office for Statistics Regulation's oversight function, which data journalists can use to challenge misleading statistics. The OSR publishes public interest reports and compliance assessments.
Do I have to publish a methodology note with every data story?
There is no legal requirement, but publishing a methodology note is best practice strongly recommended by the ONS Code of Practice, the Data Journalism Association, and UK investigative newsrooms. It demonstrates transparency, allows readers to scrutinise your work, reduces the risk of successful corrections demands, and is increasingly expected by serious publications. At minimum, include a brief methodology note within the article; longer investigations warrant a full separate document.
When does using personal data in data journalism require GDPR compliance?
Under UK GDPR and the Data Protection Act 2018, using personal data for journalism benefits from the "special purposes" exemption (DPA 2018 Schedule 2, Part 5), which disapplies most GDPR obligations where processing is necessary for journalism in the public interest. However, the exemption applies only to the extent that compliance would be incompatible with journalistic purposes. Where you hold personal data, you should still minimise it, secure it appropriately, and delete it when it is no longer needed for the journalistic purpose.
What does a data cleaning log need to include?
A data cleaning log should record: every transformation applied to the raw data (what was changed, why, and how); any rows or records excluded and the reason; how missing values were handled; any assumptions made about ambiguous data; and who performed each step and when. The log serves as an audit trail that allows you or another journalist to reproduce your work and enables an editor to understand every decision that shaped the final analysis.
What is a hash and why should I record it in my data source log?
A hash (or checksum) is a fixed-length string generated from a file's contents using an algorithm such as SHA-256. If a single byte of the file changes, the hash changes. Recording the hash of your raw data source at the time of download provides proof that the data has not been altered since you obtained it — which matters if a public authority later updates or removes the dataset. Free tools such as certUtil (Windows) and shasum (Mac/Linux) generate SHA-256 hashes from the command line.

Related packs

Related guides