Secure Data Exchange: Prepare Spreadsheets for Public Sharing

Before sharing a spreadsheet, decide whether you are sending records to named collaborators or publishing data for anyone to explore. These are different tasks: private exchange needs access controls; public publishing needs a dataset approved for public access.

For example, a researcher might keep workshop registrations private while publishing quarterly attendance by region. The useful result is a separate, documented summary—not the working workbook with names hidden.

Choose the sharing route first

For private exchange, use your organisation’s approved service. Check that it authenticates recipients, restricts access to the intended people, protects files during transfer and storage, and records transfers where required. NIST’s 2020 secure file exchange guidance describes encryption, integrity checking, authentication and auditing as capabilities of managed file transfer solutions. It also warns that third-party providers may be able to access stored files.

For public publishing, assume anyone can read and copy the released information. Reuse permissions still depend on the applicable licence or terms. Encryption during transmission does not make the resulting public page confidential.

As of October 14, 2026, TablePage describes its workflow as uploading CSV, TSV, XLSX or XLS files to generate a public dataset page that anyone can explore without signup. That makes it a destination for an approved public release, not a private exchange channel for sensitive records.

1. Define the public table before exporting

Write one sentence describing what each row represents. Then list only the fields readers need.

For the workshop example, one row might represent one region in one calendar quarter:

Working-file field	Proposed public treatment
Participant name and email	Exclude
Registration ID	Exclude from this aggregate table
Exact attendance date	Summarise by quarter
Venue address	Summarise by region
Attendance status	Use to calculate an aggregate count
Free-text participant notes	Exclude

A fictional output could look like this:

quarter	region	attendance_count
2026-Q1	North	120
2026-Q1	South	95
2026-Q2	North	132

These invented values illustrate structure, not a safe-release threshold. Define whether the count means visits or unique people; those measures are not interchangeable.

Confirm that you have permission to publish the selected data, including any restrictions imposed by the source, licence or research agreement.

2. Check identification and disclosure risks

Removing names is not enough. Combinations of age, location, dates or unusual attributes can distinguish someone or connect their record to outside information. The UK ICO’s anonymisation guidance explains these risks as singling out and linkability.

For the proposed release, ask:

• Could a reader connect a row to a known person?
• Does a small group reveal someone’s attendance or another private attribute?
• Could totals, related tables or previous releases reveal a withheld value?

Aggregation helps reduce detail, but does not automatically make a table safe. In a fictional table with two non-overlapping categories that cover the whole population, publishing a total of 40 and one category count of 38 exposes the remaining count of 2—even if that cell says “suppressed.” The UK Government Analysis Function’s disclosure-control guidance discusses combining categories and additional suppression to protect such tables.

Use the disclosure policy appropriate to your dataset rather than copying a universal minimum count. If the review cannot establish that a release is suitable for public access, keep it in the private exchange workflow.

3. Build and inspect a separate release file

Create a new file containing only the approved rows and columns. Keep the source workbook in its controlled location.

Do not rely on hidden sheets, hidden columns or filters to remove confidential content. Microsoft notes that recipients can unhide workbook data; it also identifies comments, document properties, external links and PivotTable caches as possible sources of hidden information. Its Document Inspector guidance recommends inspecting a copy and explains that some detected items require manual removal.

For a simple public table, a data-only CSV is often easier to inspect than a working workbook. It is not encryption or anonymisation: sensitive text can still be present in its cells.

Reopen the actual export and check:

• Column names, row count and expected totals.
• Dates, place codes and identifiers for conversion errors.
• Free text for overlooked personal information or credentials.
• Suppressed values and their relationship to published totals.

Keep suppression distinct from zero. Document your marker using the principles in empty CSV fields, zero and missing values.

4. Publish the reviewed version with context

Record a release filename, version, approval date and reviewer internally. Alongside the public table, provide its source, coverage period, units, counting method, suppression rules and reuse terms.

Only upload the approved release file. Then compare the public page with that file: confirm headers, row count and representative values, and inspect any generated charts or summaries for misleading treatment of suppressed data. Use a clear caption and table summary so readers know what the rows measure and what has been withheld.

Treat each update as a new release: repeat the review, including whether comparison with earlier versions reveals information that either version alone would conceal. The disclosure-control guidance explains how combining or differencing related tables can expose protected counts.