DocsDocuments & compliance

Data privacy and retention

Consent capture under RA 10173, the three-year retention horizon, how the nightly retention sweep behaves, and which obligations still need a manual process.

4 min readLast updated September 3, 2026

A recruitment agency holds passports, birth certificates, medical results and government identifiers for thousands of people. Under the Data Privacy Act of 2012 (RA 10173) that makes you a personal information controller with real obligations. HRTEQ builds three of them into the data model: consent at collection, a retention horizon, and an audit trail of privacy events.

This page describes software behaviour, not legal advice. The mechanics below help you meet your obligations; they do not discharge them. Your privacy notice, your NPC registration, your breach procedure and your data-sharing agreements with principals remain yours. Confirm your process with your Data Protection Officer.

You cannot create an applicant without consent. dataPrivacyConsent must be literally true on the create request — the schema rejects anything else, including a truthy value that is not the boolean. There is no way to add an applicant first and collect consent later.

Three fields record it:

dataPrivacyConsentAt: Stamped server-side at creation. Not client-supplied, so it cannot be backdated through the API.
consentSourceIp: Where the consent came from, which matters for an online form far more than for a walk-in.
retentionExpiresAt: Set to three years from creation. This is the horizon the nightly sweep watches.

Creating an applicant writes two audit rows, not one: applicant.created and a separate privacy.consent_recorded. Consent is treated as its own event so it can be found without trawling record-creation history.

Consent cannot be edited away. dataPrivacyConsent is stripped from update requests. It is a recorded event, not a field you flip. Withdrawal of consent is handled as an erasure decision, not by unticking a box.

The three-year retention horizon#

Personal data should not be kept longer than the purpose requires. Every applicant therefore carries a retention date three years out from creation, and a scheduled job checks it nightly at 01:45 Asia/Manila.

The sweep selects applicants where all three of the following hold:

retentionExpiresAt is set and in the past.
Status is LEAD or INACTIVE — never ACTIVE, DEPLOYED or BLACKLISTED.
They have no applications at all.

In other words: only dormant leads who never entered a pipeline are ever considered. Anyone who was actually deployed, or is mid-process, or is on a blacklist you rely on, is untouched.

The sweep does not delete anything#

Erasure is a reviewed action, by design. Rather than deleting, the sweep creates a task titled “Retention review: applicant APP-2026-000123”, assigned to the Document Officer role, saying the lead is past its retention date and has no applications, and asking whether to erase or extend consent under RA 10173. A person decides. Automatic deletion of a record you may have a statutory reason to keep is a worse failure than keeping it a week too long.

The sweep processes up to 200 records per run, so a large backlog clears over several nights rather than producing a thousand tasks at once.

Privacy events in the audit trail#

Action	Meaning	Emitted today
`privacy.consent_recorded`	Consent captured at collection.	Yes — on every applicant creation.
`privacy.data_exported`	A subject access request was fulfilled.	Reserved. No export feature exists yet.
`privacy.data_deleted`	Personal data was erased.	Reserved. No erasure feature exists yet.

The action names exist so that when export and erasure are built they land in the same trail rather than starting a new one. See Audit trail.

Who can see personal data#

Two independent mechanisms limit exposure, and both are enforced server-side.

Tenant isolation. Every tenant-owned row carries an organizationId, and a database-layer guard throws on any query against a tenant table that lacks an organization filter. An accidentally unscoped read fails rather than leaking.
Surface guards on files. An applicant may open only their own documents or files shared in a conversation they are in. An employer contact may open only conversation attachments — never an applicant’s documents. File links resolve through the API, and object-storage URLs are signed for 300 seconds.

Within the agency, every staff role can read applicant records. That is a deliberate choice — the platform exists to coordinate handoffs between officers — so the control on internal access is the audit trail rather than partitioning. See Roles and permissions.

Minimisation in the data model#

Two places where the schema takes a position worth knowing:

A principal does not see an applicant’s contact details until the endorsement decision reaches SELECTED, and the reveal is audited. See Endorsements.
A position’s ageMin, ageMax and sexPreference are internal matching fields and must never be published to a job board. Publishing them converts a principal’s stated requirement into your discriminatory advertisement.

What you still have to do manually#

Subject access and erasure have no feature yet. If an applicant asks for a copy of their data, or asks you to erase it, there is no screen or endpoint that produces either. The retention sweep raises a review task; acting on that task is manual. Plan a documented manual procedure, and record what you did — the audit action names are reserved for when the feature exists.

Also outside the product: your privacy notice and its versioning, NPC registration, breach notification, data-sharing agreements with principals and clinics, and the retention schedule for documents that statute requires you to keep longer than three years.

Was this page helpful?