Audit Log and Support Access: Who Changed What, When

Imagine Marta, office manager at a 250-person company with two floors and a car park. Tuesday, 9:50. Three people message her within ten minutes: their desk bookings were released as no-shows, although they arrived at 9:40 like every week. Something changed, and nobody remembers changing it. There are four admins in the organisation, plus an integration that syncs users from the company directory. The question is simple: who changed what, and when?

A week later her data protection officer asks a different question for the annual vendor review: "Has the software vendor looked into our data this year, and if so, when?" Questions like that are often answered with a policy document. Marta would like to answer it with a list.

This article shows how the Desk & Park audit log answers both questions, step by step, and what it does not do.

Step 1: open the audit log and find the change

Admins find the log under Audit Log. At the top are three counters: events in the last 24 hours, warnings and critical events. Below is a table of the most recent entries, newest first, with these columns:

• Timestamp: when it happened.
• Severity: Info, Warning or Critical.
• Actor: the e-mail address of whoever made the change, with their role underneath, or "system" for automatic actions.
• Action and Resource: what was done and to what kind of object.
• Details: the values involved, for example role: MEMBER → ADMIN for a role change.
• IP Address: where the request came from.

Marta types "policy" into the search box ("Search by actor, action, or details"). The entry is there: yesterday at 17:12, one of the admins changed the booking policy and shortened the check-in deadline. The entry records the values before and after the change, so the conversation that follows is about whether the new deadline makes sense, not about who did it. (If you are tuning that deadline, our article on ghost bookings and automatic release explains the trade-off.)

What gets recorded

The log covers the changes an admin would ever need to reconstruct: users and roles, reservations, spaces and maps, locations, the booking policy, integrations, single sign-on and SCIM settings, calendar sync, visitors, kiosk devices and backups. Changes made automatically by SCIM provisioning appear too, so "the directory deactivated this person" is distinguishable from "an admin did".

Each entry stores the actor and their role, the action and the object it touched, the outcome, the before and after values, the IP address and the browser's user agent.

The severity filter

Role changes, deactivations and deletions are marked Warning. Failed actions are Critical. Filtering by severity is the fastest weekly review: set the filter to Warning, scan who was promoted or deactivated, done.

Step 2: the security feed, merged into the same table

Content changes are only half of the picture. The same table also shows the security feed: successful and failed sign-ins, lockouts after repeated failures, two-factor codes required and failed, two-factor turned on or off, password resets and changes, and reuse of a revoked session token. A failed sign-in, a lockout or a reused token shows as Critical; switching two-factor off shows as a Warning.

For Marta this means one place to look. If an account was locked out at 7:00 and its role changed at 7:05, both rows sit next to each other.

Step 3: answer the DPO, support access is logged in your own log

Now the second question. When the platform operator, the team that runs Desk & Park, opens your organisation's support view to help with a ticket, the system writes an entry into your organisation's own audit log. It appears as TENANT SUPPORT ACCESS, with the operator's e-mail address, the time and the IP address.

So Marta types "support" into the search box and gets the answer as a list: when someone from the vendor side opened the organisation's data, and who it was. That is the difference between "we have a policy" and "here is the record". The entry lands in your log, not in a log only the vendor can read. Because the page shows the most recent entries, Marta makes this check a monthly habit and keeps the export, rather than waiting for the annual review.

Where the log lives, and how long it stays

Each organisation in Desk & Park has its own PostgreSQL database, with its own database login role, and the audit log is stored there, alongside your users, maps and bookings. We explain why that architecture matters in why your workplace data needs an isolated database. The security feed is kept by the platform's sign-in service and shown to you filtered to your organisation.

Audit and security entries are kept for 365 days by default and then deleted automatically, in line with the retention periods in the privacy policy. Around the log sit the other controls an admin has over the organisation's data:

• Nightly encrypted backups of the organisation database, which the organisation's admin can switch off.
• A JSON export of the organisation's data, for admins.
• A deletion request for the whole organisation.

The data processing terms are in the DPA.

Practical tips

• Give everyone their own admin account. A shared "admin@" login makes the Actor column useless. One person, one account.
• Do a weekly five-minute review. Filter by Warning, then by Critical. Look for role changes you did not expect and repeated failed sign-ins.
• Keep a copy if you need longer history. The Export CSV button downloads the entries currently loaded on the page, which are the most recent ones. If your auditors want more than a year, export on a regular schedule and store the files with your other compliance records.
• Add support access to your vendor review. Once a month, search for "support", export the result and file it for the annual review. It takes a minute.
• Pair the log with strong admin sign-in. The log tells you what happened; two-factor on every admin account makes it less likely that something bad does. See SSO, passkeys and two-factor sign-in.

Scope: what this does not do

The admin page shows the most recent entries and offers free-text search and a severity filter over them, not filtering by date range. The CSV export covers the entries loaded on the page, not the full year. There is no streaming of audit events into a SIEM. Entries older than the retention period are deleted, so long-term archiving is your export, not the product. And the isolation described above is a separate database per organisation, not separate hardware.

FAQ

Who can see the audit log?

Admins of the organisation. The page shows content changes (users, roles, bookings, maps, policy, integrations) and the security feed (sign-ins, failures, lockouts, two-factor and password events) in one table.

Can we see when the vendor's support team accessed our data?

Yes. When the platform operator opens your organisation's support view, a TENANT SUPPORT ACCESS entry with the operator's e-mail, time and IP address is written into your own audit log. Search for "support" to list the recent ones, and export them regularly if you want a full-year record.

How long are audit entries kept?

365 days by default; older entries are deleted automatically. If you need a longer history, export the log to CSV regularly and keep the files yourself.

Can we filter the audit log by date?

Not on the admin page. You can search the most recent entries by actor, action or details, filter them by severity, and export them to CSV for further analysis in a spreadsheet.

Is the audit log stored separately from other customers?

Yes. Each organisation's audit log is stored in that organisation's own PostgreSQL database, together with its users, maps and bookings.