Security & procurement

An audit log you can check, not just read

Every change in CardOffice is written to an audit log that is numbered, chained and signed, so a missing or altered entry shows. You can verify it yourself, export it as a signed file, and stream it to your own SIEM as it is written.

Stream to your SIEM Read the technical reference
Illustration of dark glass cubes filled with glowing binary digits, joined one to the next by short chains

What is recorded

An ID system is trusted on its record of who did what. CardOffice records every change to your organisation's data, not a sample of it, and keeps the record after the person who made the change has left.

  • Who: a named person, an API key, a SCIM sync or another connector.
  • What changed: the before and after value of each field.
  • When and from where: the time, the IP address and the browser.

What it covers

  • Cardholders and photos: created, updated, approved, rejected, archived, restored.
  • Cards and digital IDs: issued, printed, reprinted, revoked.
  • Orders and print jobs, from submission to dispatch.
  • Users, roles, settings and security changes, including single sign-on and two-factor settings.
  • Sign-ins, including refused ones and the reason they were refused.
How it works

A chain, written by the database itself

The protection is not in the screen that shows the log. It is in the database underneath, where no part of CardOffice can get around it.

  1. Every entry is numbered. Each organisation has its own chain, numbered from 1 with no gaps, so a missing entry is a missing number.
  2. Every entry is linked to the one before it. Each carries a hash of its own content and the hash of the entry before it, computed by the database as the entry is written. Change one entry and every link after it stops matching.
  3. Entries cannot be edited or deleted. The database refuses it, whatever asks. The one exception is a redaction of personal details under a privacy request or your retention policy: the entry keeps its place and its hash, is marked as redacted, and the redaction is recorded as an entry of its own.
  4. Every day is sealed and signed. Just after midnight, CardOffice writes a digest of the previous day's entries (the first and last number, the count and the hash at the head of the chain) and signs it with our Ed25519 audit key. The public half of that key is published for anyone to use.

Why we say tamper-evident, not tamper-proof. No log kept by a supplier can honestly promise that the people who run its servers are physically unable to touch it. What a chain promises is that any change shows: alter, remove or insert an entry and the chain, the signed digests and every copy you hold stop agreeing. The strongest assurance is a copy we cannot reach, which is what streaming to your own SIEM gives you.

Verification

Check it yourself, three ways

A claim about integrity is only worth as much as the means to test it. These are in the product, not available on request.

Verify in the portal

Under Settings, Audit log, one button recomputes every entry in your chain and checks every link and number. Any fault is reported by its position. The check is itself logged, so a verification is part of the record.

Export a signed file

Download any date range as one entry per line in chain order, with a trailer carrying a SHA-256 of the file and our signature. Your auditor checks it offline with a short script and the public key, without having to trust the server that produced it. A CSV of the same columns is there for spreadsheets.

Match the public key

Our signing key is published at a fixed address that needs no account. Every digest and export names the key that signed it, so a file signed before a key rotation still verifies against the right one.

SIEM integration

Stream every entry to your own SIEM

Your security team should not have to log in to CardOffice to see what happened in it. An administrator adds a stream under Settings, Audit log, Streams, and from then on every entry is sent to your collector within about a minute of being written. There is no agent to install.

Each stream keeps its own place in the chain. If your collector is down for maintenance, or for a weekend, it receives everything it missed when it comes back, in order, and nothing is sent twice. Because every entry arrives with its number and hash, your SIEM can raise its own alert on a gap.

Syslog over TLS

RFC 5424 with octet counting (RFC 6587), one message per entry, facility log audit. The entry's number, hash and organisation are in the structured data and the full entry is the message, as JSON. Your collector presents a certificate from a public certificate authority.

Signed HTTPS webhook

Batches of up to 200 entries, posted as JSON to your URL and signed with the stream's secret exactly as every other CardOffice webhook is, so the receiver can prove the batch came from us.

Field-by-field formats and examples are in the audit log reference.

Retention and privacy

Kept as long as you need, private when it should be

  • Kept indefinitely by default. Audit entries are not aged out unless your organisation sets a retention period.
  • Retention that still verifies. If you do set a period, old entries are removed only up to a signed daily digest, so the chain that remains still checks out from end to end.
  • Personal details do not outlive their purpose. When a person's record reaches the end of its retention, or a privacy request is actioned, the personal fields inside their audit entries are blanked. Card numbers, dates and the chain stay, so “who held card 12345 in 2024” is still answerable as a record.
  • Legal hold on a person stops that clock for an investigation, a complaint or an information request.

How retention runs, step by step, is in the security and data architecture notes.

For your questionnaire

The logging questions, answered

The lines that come up in nearly every security review, with the short answer and where it lives.

The question The answer
Are administrator and privileged actions logged? Yes. User, role, settings and security changes are logged alongside every data change, with the person or system that made them.
Are failed sign-ins logged? Yes, with the reason the sign-in was refused.
Are logs protected against modification and deletion? Yes. Entries are hash-chained and numbered by the database, which refuses edits and deletions; each day is sealed by a signed digest.
Can integrity be verified independently? Yes. Signed exports verify offline against a published Ed25519 public key.
Can logs be forwarded to our SIEM? Yes, in near real time, as syslog over TLS or a signed HTTPS webhook, with catch-up after an outage.
How long are logs retained? Indefinitely by default, or for a period your organisation sets.
Can we obtain logs for an investigation? Yes. An administrator exports any date range from the portal at any time, without raising a request with us.

Frequently asked

Is the CardOffice audit log immutable?

Entries cannot be edited or deleted: the database refuses it, whatever part of CardOffice asks. The one exception is a redaction of personal details under a privacy request or your retention policy, which is marked on the entry and recorded as an entry of its own. We describe the log as tamper-evident rather than tamper-proof because that is the claim we can prove: any change, removal or insertion breaks the chain and shows up when it is verified.

Which SIEM or log platforms does it work with?

Any collector that accepts syslog over TLS (RFC 5424 with octet counting) or an HTTPS webhook. Most SIEM and log platforms accept one or the other without a plug-in. Each entry is sent as JSON with its sequence number and hash, so your platform can parse it and check for gaps itself.

What happens if our collector is down?

Nothing is lost. Each stream keeps its own position in the chain, so when your collector comes back it receives everything it missed, in order, and nothing is sent twice.

Could CardOffice staff alter our audit log?

Not without it showing. The application cannot write outside the chain, the database refuses edits, and each day is sealed by a signed digest. An entry changed directly in the database would fail verification. For an organisation that wants assurance that does not depend on us at all, streaming keeps a copy in your own systems that we cannot reach, and a signed export can be checked offline against our published public key.

Who in our organisation can see the audit log?

Administrators, and anyone you give a role that includes audit access. Seeing the log and managing streams and exports are separate permissions, so a compliance reviewer can read without being able to change where the log is sent.

How long are audit entries kept?

For as long as your account runs, by default. If your organisation sets an audit retention period, older entries are removed only up to a signed daily digest, so what remains still verifies. When a person's record reaches the end of its retention, the personal fields inside their audit entries are blanked while card numbers, dates and the chain itself stay.

Bring us your questionnaire

If your review asks about logging, monitoring or evidence for an audit, send it ahead of the consultation. We will work through it line by line, and can stream a trial organisation's log to your collector so your security team sees it arrive.

Book a consultation Back to security & procurement