Design note: selective disclosure and audit records

Development status: Research — This note records goals, assumptions and open questions; nothing here is an assurance or a released feature. Owner-controlled visibility, time-limited access for auditors to the data itself, the separation of seeing from acting and the selective disclosure of results are being explored, and tamper-evident audit logging is part of the planned design, with an experimental library for internal development. The experimental implementation provides no encrypted or access-controlled data and only simulates the step that would reveal results, and nothing is publicly available for live use.

Before you read: Problem statement and intended properties.

What properties are intended for sharing data selectively and keeping audit records, and what is assumed of auditors? This note gives the research view of two related goals: letting data owners share selected data and results with chosen parties — including auditors, for a limited time — and keeping records of significant actions in which alterations can be detected. It states each property as a goal, sets out what would be assumed of data owners, auditors and those who keep records, records what exists today and lists the open questions. Access and record-keeping mechanisms are not described.

Motivation

Organisations often need to show specific information to auditors, partners or reviewers — not everything, and often only for a period.

Both easy answers fail. Sharing whole datasets over-exposes data that the reviewer never needed, while refusing to share blocks oversight and collaboration that the organisation may want or be obliged to support.

Records of significant actions support accountability and later review, but only if alterations to them can be noticed. A record that could be quietly changed would give a reviewer little to rely on.

The two goals are related but separate: one concerns who can see data, the other concerns what happened. This note treats them side by side because the same readers — auditors, assurance teams and the organisations they review — tend to need both.

Intended properties for selective sharing (each a goal)

• Owner-controlled visibility — Being explored. Data owners would decide who can see which data. See visibility.
• Time-limited access for auditors — Being explored. An owner could give an auditor access to specific data for a limited time, and the auditor would see the data itself during that period. See time-limited access.
• Seeing separate from acting — Being explored. Who may see data would be controlled separately from who may act on it, so that being able to see would not grant authority to act. See approval authority.
• Selective disclosure of results — Being explored; the reveal step is only simulated. Selected results could be disclosed to authorised parties instead of all the underlying data. See selective disclosure.

How visibility would be expressed, enforced or changed is not described.

Intended properties for audit records (each a goal)

• Tamper evidence — Planned. Alterations to records of significant actions could be detected when the records are checked. See tamper-evident log.
• Tamper-evident is not tamper-proof. Alterations would be detectable on checking, not impossible.
• Reviewability — Planned as part of audit logging; the governance steps it would cover are themselves being explored. Significant actions, such as the steps of a governance decision, are intended to be reviewable afterwards through an audit trail.

Which actions would be recorded, how records would be kept and who could consult them are not described.

What would be assumed of data owners, auditors and record keepers

In short, for auditors: an auditor would be given access by a data owner, for a defined scope and period; would see the data itself during that period; would be responsible for handling what it has seen, because copies cannot be recalled; and would gain no authority to act from being able to see. Today, no auditor has access to anything.

In more detail:

• Data owners would decide what to share, with whom and for how long, and would review access over time. The design would not make these decisions for them.
• Auditors would be granted access by a data owner for a defined scope and period, and would see the data itself during that period. They would handle what they see under their own obligations, because copies cannot be recalled, and they would gain no authority to act from being able to see.
• Record keepers and checkers. Tamper evidence would depend on someone checking records, and on trust in whoever keeps the records.
• Organisations would remain responsible for their own legal and regulatory obligations. See Compliance position and data-protection intent.

How auditors or other parties would be identified and authorised is not described.

Limitations, and what the experimental implementation shows

Status of this section: Experimental implementation exists for an internal tamper-evident logging library; nothing described in this note is available.

• The experimental implementation provides no encrypted or access-controlled data, and no visibility settings, auditor access or disclosure features are available.
• The step that would reveal results to authorised parties is only simulated.
• An experimental library implementation of tamper-evident logging exists for internal development. It is not a complete audit system, no records produced with it are published, and no durability or completeness is claimed. See Audit trails and tamper-evident logging.
• No auditor, regulator or other party has access to anything today.
• No legal, regulatory or evidentiary standing is claimed for any record.

Open questions

• How would visibility choices be expressed, changed and reviewed over time?
• What would remain with an auditor or partner after time-limited access ends, and how should data owners plan for that?
• How would the separation of seeing from acting be kept consistent as permissions change?
• Which actions would be recorded, and how, and by whom would records be checked?
• How would records be kept dependable over time, including across failures?
• How would these properties be evaluated? See Evaluation methodology and published results.

These questions also appear in the consolidated list on Assumptions and open questions. No answer is published, and none should be inferred from the way a question is phrased.

Assumptions, trust and limitations

• These properties are goals; their assumptions are stated qualitatively and may change.
• Visibility controls could limit who is given access, but they cannot stop someone with access from copying what they see.
• Tamper evidence helps detect some changes, but it does not prevent them.

Not yet available, and how this page will grow

• Further technical reference is not yet available.
• Once the capabilities are implemented and released, their pages would describe how visibility is configured and how records can be checked, and this note would link to them.
• If reviewed design material is approved for publication, it would be linked here with its date. A superseded note would keep its address with a “not current” banner.

What this note does not claim

This note does not claim:

• any access-control mechanism, enforcement or disclosure procedure;
• any assurance that only authorised parties could read data;
• any auditor or regulator access today;
• that records would be tamper-proof or complete;
• any legal, regulatory or evidentiary standing.

Anything not stated here as available or assured should be treated as neither.

Related pages

• Visibility controls and selective disclosure — the capability page for owner-controlled visibility and disclosure.
• Audit trails and tamper-evident logging — the capability page for audit records and the experimental library.
• Compliance position and data-protection intent — why none of this is a compliance claim.
• Assumptions and open questions — these questions in the consolidated list.

Glossary

• Visibility
• Selective disclosure
• Data owner
• Time-limited access
• Auditor
• Audit trail
• Tamper-evident log
• Approval authority

References

No approved public references yet.