Automated, configurable data-retention and anonymization for access-control deployments – built for security teams who need to prove compliance, not just claim it.
Wherever your customers operate, personnel data in an access-control system is regulated personal data.
ISO 27001, SOC 2 and NIST already prescribe what good retention looks like. Privacy Guard implements that prescription end-to-end.
Per-partition, per-personnel-type windows defined in the admin client and versioned in a dedicated database.
Every cycle, every record, every server – per-user processing state queryable on demand for auditors.
Preserve forensic evidence by anonymizing; remove obligation entirely with controlled, traceable deletion.
At-least-once semantics. A failed cycle never leaves the system in a half-applied state – re-runs are safe.
C·CURE 9000 ships with a retention switch: keep everything forever, or delete everything older than X days – globally.
"Delete journal after X days" is system-wide. No per-personnel-type, no per-partition, no per-role variations.
Keep employee data seven years and you keep visitor data seven years. Over-retention is the default outcome.
The native cleanup deletes whole rows. You cannot keep an audit event for forensics while removing the identity attached.
Hand-written cleanup scripts per category. No audit of what ran, no coordination across MAS-SAS servers.
Out of the box, access-control systems are over-retentive by default – and over-retention is non-compliance dressed up as caution.
A configurable privacy and data-retention pipeline for C·CURE 9000 – anonymizing personnel data, audit logs, and activity logs on the schedule you define.
Policy-driven. Runs on a CRON schedule, every server, every cycle. No manual SQL.
Per-server, per-user processing state in a dedicated database. Every action traceable.
Storage limitation, right to erasure, regional retention – enforced by design.
Same proven engine – re-architected for enterprise deployments and modern compliance demands.
Build a retention policy once with these three primitives. Privacy Guard does the rest.
Each processing server has its own schedule. Run nightly at 02:00, weekly during off-peak, or per regional timezone in multi-server deployments.
Rules that produce a list of personnel records. Six types cover every realistic selection: flagged, partitioned, by personnel type, deleted, anonymized, or none.
What to do to the selected records. Anonymize the audit log, delete activity entries, generate a CrossFire import to rewrite the personnel record, sync last-badge dates.
A single criterion can feed multiple processors. A single processor can run on the union of multiple criteria.
What anonymization actually looks like
A former employee's record, still searchable by name
The personnel record is gone. The name is not. Every door event and every audit line still identifies the cardholder – sometimes years after departure.
Statistics preserved. Identity removed.
The audit trail and the door statistics survive – required for security and reporting. The personal identifiers are gone – required for data minimization.
Manual cleanup deletes everything or nothing. Privacy Guard separates the two: it keeps the operational record an auditor needs while removing the personal data a regulator says you shouldn't keep.
Operator-flagged. Selects personnel whose UDF checkbox is ticked. Used for one-off, right-to-erasure requests handled by a security operator.
By partition. Selects everyone in a named C·CURE partition. Optional filters: last-modified threshold, days-inactive, completion UDF.
By personnel type. All visitors, all contractors, all employees – selected by Id or Name with the same optional filters as partitions.
From the audit log. Anyone whose deletion is recorded in the SAS audit log since the last run. Drives the cleanup of orphaned records.
Already anonymized. Personnel whose GUID has been rewritten to the canonical anonymized value. Used for post-anonymization mop-up.
Produces a CrossFire XML import that rewrites the personnel and credential rows on the SAS – propagated across MAS-SAS sync.
Replaces personnel names in audit entries and clears field-level audit detail. The audit trail stays intact – the person is no longer identifiable.
Replaces names in activity journal entries while preserving the events. You still see that a door opened – you no longer know by whom.
Removes all activity journal entries for the supplied users – ideal for visitor cleanups and short-retention groups.
Removes activity journal entries older than DaysThreshold for the supplied users. The classic "keep 30 days, delete the rest" rule.
Maintains a complete last-badge timestamp per person on the MAS so days-inactive criteria work correctly across every SAS.
A UDF on the personnel record.
Checked by an operator in the C·CURE Client.
Renders the anonymization template into a CrossFire XML import – rewrites the personnel record on the SAS.
Strips the cardholder's name from Activity Journal entries – events remain for statistics, identity does not.
Replaces personnel names in Audit Log entries and clears field-level audit detail.
One to many One criterion can feed several processors; one processor can run on the union of several criteria.
Here are 5 sample scenarios that demonstrate how a Privacy Tool can help organizations protect sensitive personal data within Access Control.
Personnel who haven't badged in 24 months are former employees, departed contractors, or visitors who never returned. Keep them on file and you carry the privacy exposure for no business value.
Two-year storage limitation, enforced automatically – with the historical record preserved for statistics.
Visitors generate a high volume of access events you have no business need to retain. Apply a strict, short retention to visitor activity without touching employee or contractor data.
Visitor data minimized to a 30-day window; employee and contractor records remain governed by separate policies.
Audit and activity logs are valuable – for forensics, for statistics, for proving an event happened. They become a liability only when they still name a person who is no longer there.
Every door event and every operator action preserved – none of it tied to a named person who is no longer with you.
GDPR Article 17 gives data subjects the right to erasure on request. Your operator opens the personnel record, ticks one UDF, saves. Next cycle, that person is anonymized end-to-end.
From data-subject request to full anonymization in one operator action – and a single processing cycle.
Global deployments mean diverging rules: EU sites under GDPR, US sites under CCPA, regional works-council agreements on top. Apply per-partition policies side by side without forking configuration.
All sharing one admin client.
Every region runs its own retention policy, audited centrally, with no per-site SQL or scripting.
Privacy Guard installs on every C·CURE server it manages. State and configuration are shared through a dedicated database.
A single C·CURE server hosts the CCURE database and the PrivacyGuard database. One service, one schedule. Ready in minutes.
One service per SAS, coordinating through a central PrivacyGuard database on the MAS. Per-region schedules, global criteria, no duplicate work.
Defined in the admin client. Versioned in the PrivacyGuard database. Auditable on demand by your DPO.
CRON-scheduled per server. Per-region timezones. Fail-fast with no half-applied policy.
Per-user, per-server processing state. Diagnostic views to show exactly what was done, when, and where.
One UDF tick, one cycle. Erasure requests handled in 24 hours instead of weeks.
Configure servers, criteria, processors and CRON schedules from a single admin client. Click any screen to enlarge.
Request a demo, a temporary license for your pilot, or a quote for production. Most licenses are issued within 24 hours during business days.