Data Subject Rights and GDPR Compliance in MeetCost

MeetCost is software you run, not a service anyone operates for you. That means there is no processor to sign a Data Processing Agreement with — you are the data controller of everything in your deployment. This page describes what personal data MeetCost holds, how to service data subject rights using the API, and the technical and organisational measures the system provides. It is a description of what the software does, written so that your privacy counsel, DPO, or works council can assess it quickly. It is not legal advice, and the obligations are yours.

Personal data MeetCost holds

Data	Category	Source	Retention
Work email, name, team, manager	Personal	Your directory	Until directory sync marks the person inactive
Pay amount, currency, effective date	Treat as sensitive — equivalent to special category in practice	Your CSV upload or HRIS	Until deleted; versioned, never overwritten
Meeting title, times, attendee list	Personal	Your calendar system	Indefinite unless you prune
Attended minutes per person	Personal and behavioural	Provider attendance reports	Indefinite unless you prune
Access to pay data — who, when	Personal	Generated by the system	Indefinite by design

Pay is not “special category” under GDPR Article 9 in most readings, but it is among the most sensitive data an employer holds about someone. MeetCost’s protections treat it that way throughout.The row that most often surprises people is attended minutes per person. It is behavioural data about individuals, and it is the row a works council will ask about first.

Before you deploy

Work through these with whoever owns privacy at your organisation.

Establish a lawful basis

Most European deployments land on legitimate interests (Article 6(1)(f)) for cost analysis of meetings. Consent is a poor fit in an employment relationship, where it is rarely freely given. Produce a legitimate interests assessment, and ensure the balancing test engages honestly with the fact that this system can measure individuals.

Assess whether a DPIA is required

Processing employee pay data alongside behavioural (attendance) data will usually meet the threshold for a data protection impact assessment. Conduct it before deployment, not after the first complaint.

Consult works council or employee representatives

In Germany, the Netherlands, France, and elsewhere, a system capable of monitoring employee behaviour requires consultation or co-determination before it goes live. This is not a formality. Involve representatives early — the position that MeetCost is a meeting-hygiene tool rather than a performance tool is much easier to make when representatives helped set the configuration.

Be transparent with employees

Employees should be told this exists, what it measures, and who can see what. A short internal note referencing your configured settings is usually enough. Deploying it quietly is the single fastest way to turn a cost-hygiene tool into a surveillance story.

Check applicable national law

The Ghana Data Protection Act 2012, and similar regimes in other jurisdictions, require registration with a data protection authority and confer data subject rights on employee data on the same terms as GDPR. The API mechanisms below cover the technical side of those rights regardless of jurisdiction.

Data subject rights

Access
Erasure
Rectification
Objection and restriction

“What do you hold about me?”Use these two endpoints to retrieve a person’s pay history and a full record of who has accessed it.

# Pay records, including every historical version
curl -s "https://your-meetcost/api/v1/admin/pay?search=person@example.com&reveal=true" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

# Who has looked at this person's pay data, and when
curl -s "https://your-meetcost/api/v1/admin/audit?target=person@example.com&days=3650" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

The reveal=true flag on the first request is itself audited — servicing an access request leaves its own trace in the log, which is the intended behaviour.

“Delete my pay data.”

curl -X DELETE "https://your-meetcost/api/v1/admin/pay/person@example.com" \
  -H "Authorization: Bearer $ADMIN_TOKEN"

This removes every version of that person’s pay record. Their past meetings keep the costs already computed — those are historical financial aggregates, and recomputing or voiding them is usually neither required nor desirable under Article 17.If your assessment says otherwise, delete the meeting_participants rows directly; the meeting totals will no longer reconcile, which is the trade.

The audit log is deliberately not erasable through the API. A log of who accessed someone’s salary is a protection for that person, and the retention case for it is strong. Your counsel may disagree; if so, delete directly from audit_events and record why.

“Correct my record.”Upload a corrected pay record:

Same effective_date as an existing record → replaces that version in place.
New effective_date → adds a version rather than rewriting history.

The versioning is intentional. A meeting costed last quarter should still be explainable with the rate that applied then.

“Stop processing my data” / “Restrict processing.”There is no per-person opt-out flag. The practical mechanism is to delete the person’s pay record: they are then priced at the org-wide fallback rate and labelled as an estimate, and no individual figure about them is held or processed.

# Remove pay record (see Erasure tab for the full DELETE command)
# After deletion, this person's meetings display as estimated cost

Technical measures

Measure	What it does
AES-256-GCM on pay amounts	Encrypted at rest under a key you supply and hold. MeetCost cannot recover your data without it and has no key-escrow mechanism
Ciphertext bound to the subject	Additional authenticated data ties each ciphertext to the employee’s email address. A row copied between employees fails to decrypt rather than silently reporting the wrong person’s salary
Masked by default	Pay figures are not rendered unless someone deliberately reveals them. The mask is fixed-width — an earlier variable-width version leaked the order of magnitude of a salary without going through the audited reveal path
Audit on every reveal	One row per person per event, so “who has seen my salary?” is always answerable. A single bulk-export row would not serve that question
Role-based access	Raw pay is Admin-only by default; Finance access is a separate, off-by-default flag. See Permissions
Breakdown suppression and banding	Prevents a cost figure from being arithmetically reversed into a salary for non-admin viewers
Egress allowlist	Enforced at the socket layer. No data leaves the deployment’s configured destinations. Any connection to a host not derived from your configuration is refused before a packet is sent
No telemetry	Nothing is reported to any vendor, including this project. Not optional-and-on-by-default. Absent

Organisational measures worth having

Name someone accountable

Name a person responsible for the deployment. “Whoever set it up” is not a role and does not constitute accountability.

Review the audit log

The audit log only protects people if someone reads it. Schedule a periodic review. Use audit?target= for any person who asks.

Keep the admin set small

Admin can read every salary and change every disclosure setting. Limit admin role assignments accordingly, and audit who holds it.

Rotate service tokens

Service tokens are admin credentials. Treat them with the same rotation schedule as other privileged credentials. Leaked tokens are leaked admin access.

Separate key and database backups

Store the encryption key and the database backups in different places. Together they are the payroll file. Separately, neither is.

Produce a legitimate interests assessment

Document the balancing test before deployment, and revisit it if the configuration changes in ways that increase individual monitoring.

Data residency

The processing happens wherever you run MeetCost. There is no vendor-operated endpoint, no sub-processor, and no international transfer introduced by MeetCost itself. Directory and attendance reads go to your own tenant of Google, Microsoft, or Zoom — systems you already use, under the transfer arrangements you already have with them.

See Privacy for the connection-by-connection detail of every outbound call MeetCost makes, and server/tests/test_no_egress.py for the test that enforces these claims on every commit.

Get Started

Deployment

Features

Privacy & Security

Integrations

Data Subject Rights and GDPR Compliance in MeetCost

Personal data MeetCost holds

Before you deploy

Data subject rights

Technical measures

Organisational measures worth having

Name someone accountable

Review the audit log

Keep the admin set small

Rotate service tokens

Separate key and database backups

Produce a legitimate interests assessment

Data residency

​Personal data MeetCost holds

​Before you deploy

​Data subject rights

​Technical measures

​Organisational measures worth having

Name someone accountable

Review the audit log

Keep the admin set small

Rotate service tokens

Separate key and database backups

Produce a legitimate interests assessment

​Data residency

Personal data MeetCost holds

Before you deploy

Data subject rights

Technical measures

Organisational measures worth having

Data residency