Skip to main content

Data governance and periodic reporting

Data governance and periodic reporting help you understand the use and operational quality of Checkmate without retaining raw guest data longer than necessary.

:::info Availability

Data governance, secured archives, exports, and the reporting service are active across the platform. Periodic report emails only start after an authorised administrator configures an active subscription for your company, including its frequency, venues, and recipients. Nothing is sent without a subscription.

:::

What does this functionality provide?​

Depending on your permissions, available metrics, and agreement, Checkmate supports:

  • monthly or quarterly reports;
  • a company summary with a breakdown for selected venues;
  • comparison with the previous period and, where available, year-to-date;
  • insight into usage, guest journeys, and operational reliability;
  • clear notices when source data is incomplete or not yet reliable enough;
  • secure detail downloads from recent or archived data;
  • historical reporting periods without manually resetting annual counters.

A report only shows metrics with a verifiable source and definition. Missing data is not presented as zero.

Configuring your reports​

Where supported by the agreement, an authorised administrator selects:

  1. Frequency: monthly, quarterly, or disabled.
  2. Venue scope: all permitted venues or an explicit selection.
  3. Recipients: only people approved for the relevant company and venue scope.
  4. Language and time zone: appropriate for the recipient and report schedule.
  5. Sections: for example guest journeys, reliability, or usage.

A new configuration is first stored in a paused state. This allows the administrator to verify the venues, recipient, language, and preview before the first email is sent. Repeating the same onboarding action does not create a duplicate configuration or duplicate report email. The administrator then manages changes on the existing configuration.

Access is checked again when someone opens a report or export. Being listed as an email recipient does not grant additional access to venue or detail data.

How reporting periods work​

Checkmate does not delete the underlying history when a calendar year ends. Instead:

  1. the previous reporting period is closed;
  2. available metrics are validated and stored with their definition version;
  3. eligible history can be archived;
  4. the dashboard starts in a new annual period;
  5. permitted previous periods remain selectable for as long as their retention policy allows.

For hospitality processes, the PMS business date may be authoritative. Other metrics use the event time in the venue's time zone. This prevents a night audit or delayed PMS update from automatically being assigned to the wrong period.

A short closing window allows delayed PMS events and retries to arrive. Valid data received later can create a corrected report version. The previous version remains identifiable; figures are not silently overwritten.

What can a report contain?​

Depending on the available and approved metrics, a report may contain:

  • a concise executive summary;
  • four to six key performance indicators;
  • changes compared with the previous period;
  • guest-journey results;
  • operational reliability and integration quality;
  • AI, voice, and communication usage;
  • usage and consumption;
  • a venue overview;
  • data-quality notices and verifiable action points.

Report emails do not contain guest names, reservation numbers, telephone numbers, email addresses, document numbers, messages, or transcript excerpts. Detail information belongs in a secured dashboard or a separately authorised export, not in the email.

How unnecessary data growth is limited​

A PMS may provide the same reservation repeatedly even when its contents have not changed. Checkmate compares the meaning of these updates before adding new operational history. A difference in technical synchronisation time, capitalisation, whitespace, or common telephone-number formatting is not treated as a new guest action by itself.

When a relevant change does occur, such as a new reservation status, room assignment, or updated contact field, the event remains available to the processes configured for it. Equivalent repetitions use a stable technical key, preventing retries from being counted twice or starting a workflow twice.

For reporting events, Checkmate retains only the context required to assign and process the event securely. Raw contact values, guest names, room numbers, and access tokens are not copied into general event metadata. The underlying reservation data follows its own access and retention policy.

New operational guest events are also summarised into versioned daily counts per company, venue, reporting date, event type, and source. These summaries do not contain a guest name, contact details, reservation number, room number, or free text. This provides compact reporting statistics without requiring every raw event to remain a long-term reporting source. Raw events are only removed after coverage, archives, legal holds, and the applicable retention policy have been validated separately.

History, archives, and exports​

Where proportionate and permitted, eligible operational history, usage, statistics, and audit information can remain available for multiple years. Five years is a business objective for suitable data categories, not a general retention period for all personal data.

Each download is generated again from authorised source data or a controlled archive. Depending on its purpose, it can be a PDF, CSV, or JSON file. Downloads:

  • require authentication and authorisation for the correct company and venues;
  • never use a permanently public storage link;
  • are available for a limited time;
  • are logged for audit and security purposes;
  • contain only the datasets, period, and fields permitted for the request.

An archive is not a backup. The archive supports controlled access to historical data. Backups are intended only for recovery after an incident.

Backups and recovery​

Checkmate creates a managed database backup every week for production only. A maximum of four rolling weekly restore points remain available; once a backup is four weeks old, the cloud provider removes it automatically. Production also has a shorter point-in-time recovery window for recent errors. Development does not build a recurring backup history; technical test data can be cleaned separately through a bounded manual process.

A backup is not an additional customer archive and cannot be used as a normal detail download. During an incident, a backup is first restored to a separate, isolated database. Checkmate validates its contents, counts, and consistency before deciding how recovery should proceed. The active production database is not overwritten without control, and the platform does not normally need to be taken offline for this validation.

This recovery path is verified every quarter using the latest suitable production backup. The drill never restores over the active database; it restores only into a protected temporary database. It compares representative counts, does not expose document content, and removes the temporary restore database after successful validation. A failed drill stops safely and alerts the operations team.

Automated housekeeping​

To prevent unnecessary database growth, Checkmate suppresses repeated events at the source and removes short-lived technical logs and narrowly scoped operational observability data in a controlled way. The active technical policy covers three types of scheduler and integration diagnostics; raw records older than 30 days are processed in small batches. A second policy only covers reservation lookups and device activity after a default of 90 days, and lifecycle and notification-delivery facts after a default of 365 days.

This technical housekeeping does not delete companies, venues, users, devices, integration configuration, reservations, guest profiles, messages, invoices, or usage data. Operational guest events and data that may be needed for reporting or billing first receive their own approved aggregation, archive, and retention policy.

A legal hold blocks the relevant dataset or matching record. Every run has a hard maximum size, uses update preconditions, and was validated in dry-run mode before activation. This ensures that “keeping the database healthy” is not treated as a broad annual reset. Operational guest events, usage, and billing are outside this automatic cleanup.

When are reports sent?​

The reporting scheduler checks each day which active monthly or quarterly subscriptions are due. Each run processes a bounded number of subscriptions, and a deterministic run key prevents duplicate reports. Checkmate only sends a report when:

  • the subscription is active;
  • the recipient is still authorised for the selected venues at delivery time;
  • the reporting period and metric version are unambiguous;
  • required data-quality and privacy controls pass.

An administrator can disable the subscription. The platform kill switch can stop new deliveries immediately without deleting historical reports or source data.

Why not all data is retained for five years​

Personal data should not be retained longer simply because it is technically possible. Purpose, necessity, contractual arrangements, and applicable law are considered for each data category.

Data categoryPrinciple
Aggregated reports and eligible operational historyCan remain available for multiple years where the purpose and re-identification risk allow it.
Reservation and PMS dataRetained only for as long and in as much detail as needed for the stay, synchronisation, support, and applicable obligations. Full provider payloads are not archived by default.
Messages, chat, and transcriptsContent receives a purpose-bound and generally shorter period. Metadata or aggregated usage may remain useful longer than the content.
Identity dataOnly the permitted minimum. An identity-document copy or Dutch citizen service number (BSN) is not treated as general reporting or archive data.
Financial administrationMay be subject to a separate statutory period; Dutch core financial records generally have a seven-year retention requirement.
Guest-register dataThe hotel determines the applicable local requirements and periods for each venue with appropriate legal advice.
Technical debug logsRetained briefly and based on risk; they are not a five-year customer archive.
Security and audit informationReceives a separate, limited period appropriate for security, evidence, and contractual needs.
Backups and external providersHave their own controlled lifecycle and must not silently extend the ordinary retention period.

The exact period can therefore differ by dataset, hotel, country, municipality, contract, or legal role.

Security and privacy​

The main principles are:

  • company and venue boundaries are enforced by the server;
  • recipients only see the scope for which they are authorised;
  • small or identifiable groups can be suppressed;
  • pseudonymised data is not presented as anonymous;
  • exports and compliance actions are audited;
  • deletion is blocked if a required archive cannot be proven valid;
  • high-risk automated deletion is not enabled without approved policy and additional controls.

Checkmate does not provide permanent or direct access to external authorities. A valid request follows a controlled process for verification, scoping, approval, data minimisation, and logging.

A legal hold can temporarily block deletion for specific companies, venues, datasets, identifiers, and periods. A hold:

  • does not expand ordinary access rights;
  • has a reason, owner, and review date;
  • is fully audited;
  • returns to the normal retention policy after release.

Where the customer or hotel is the data controller, its role is included to the extent permitted by the request and applicable law.

What does your organisation need to decide?​

Before using this functionality broadly, record internally:

  • who may configure and receive reports;
  • which venues each recipient may access;
  • which metrics are relevant and sufficiently reliable;
  • which retention periods and legal roles apply to each dataset;
  • who handles access, correction, deletion, or restriction requests;
  • which local guest-register and hospitality requirements apply.

This page explains the product and is not legal advice. Always validate obligations with your organisation's privacy, legal, finance, and security owners.

Frequently asked questions​

Are dashboards erased every year?​

No. The dashboard opens a new reporting period. Permitted historical periods remain available while their retention policy allows.

Is all personal data retained for five years?​

No. Five years is only an objective for suitable operational history, usage, statistics, and verifiable reports. Raw personal data and communication content receive their own purpose-bound periods.

Can I download older data?​

Yes, when the dataset is within your authorised scope, remains available under the applicable policy, and the export type is enabled. A new secured export is generated from hot or archived data.

Does a public authority receive direct access?​

No. There is no permanent external access. A valid request is verified, scoped, approved, and audited before a minimised dataset can be disclosed.

Why can a figure differ from an earlier report?​

A delayed PMS update or quality correction can create a new report version. The report version and data-quality notice make that change visible.

Can Checkmate return to an earlier database version after an error?​

There are up to four rolling weekly backups and a shorter point-in-time recovery window for recent production incidents. Recovery is first performed in a separate database and validated before data is potentially reconciled. A backup does not guarantee that every action performed by an external provider can be reversed.

Official information​