Access and audit logging¶
Who viewed which candidate, who changed a score, who exported data — and when. This page documents SkillFoundry's audit trail: what is recorded, how long it is kept, how you access it, and where coverage is still expanding.
Two layers of logging¶
SkillFoundry keeps audit information at two layers, which serve different purposes.
1. Application audit log (business actions)¶
A durable, queryable record of meaningful actions on business objects — the log Legal and Security care about. Each entry captures:
| Field | Meaning |
|---|---|
action |
Dotted action name, e.g. task.create, submission.create, gdpr.data_export, invitation.sent |
user_id |
The actor (null for system/automated actions) |
resource_type / resource_id |
The object affected (task, submission, organization, user, consent…) |
details |
Structured context (e.g. the organization, the changed fields, a request ID) |
ip_address / user_agent |
Request origin (proxy-aware: honors X-Forwarded-For / X-Real-IP) |
timestamp |
UTC time of the action |
Entries are append-only from the application's perspective (there is no update/edit API for audit records) and are indexed by time, by actor, and by action type for efficient investigation. Audit writes are best-effort-isolated: a logging failure is caught and reported but never breaks the user action it is describing, so the log cannot be used as a denial-of-service lever.
2. Request/security telemetry (infrastructure)¶
Every HTTP request also flows through security middleware that records method, path, status, latency, auth type, IP, and user-agent, increments per-endpoint and per-status security metrics, and feeds attack-pattern detection and automated IP blocking (SQL injection, XSS, path traversal, command injection). This layer is optimized for security monitoring and incident response and has a shorter, rolling retention (on the order of days) versus the multi-year retention of the application audit log.
What is captured today¶
Actions that are explicitly written to the application audit log include:
- Authentication — login, logout.
- Task lifecycle — create, update (with a diff of changed fields).
- Submissions — creation of a submission against a task.
- Organization & membership — organization creation; invitations sent, resent, and accepted (with invitee email and role).
- Billing — subscription creation (plan and org).
- Integrations — GitHub/ATS integration creation.
- Privacy & data-subject events — data export, deletion request, deletion completion, rectification, consent granted/withdrawn, retention enforcement, DPIA runs, and breach detection/assessment (see Data retention and erasure).
Because privacy operations write to the same trail, a data-subject request produces its own auditable evidence: you can show a regulator not just that data was deleted, but who requested it, who processed it, and when.
Current coverage and gaps¶
We distinguish, deliberately, between actions that change data and actions that read it:
| Category | Status |
|---|---|
| Create / update / delete of tasks, submissions, orgs, invitations, integrations, subscriptions | In place |
| Authentication events | In place |
| Privacy / DSAR / consent / retention / breach events | In place |
| Manual score adjustments (identity + reason) | In place — recorded with the reviewer's identity and required reason (see Reviewing candidates) |
| Read access — a reviewer opening a specific candidate's report or submission | Roadmap — being rolled out across all candidate-data read paths as a first-class candidate.report.view / submission.view audit action |
| Bulk export / download of candidate data | In place for org data export (gdpr.data_export, organization export); per-report download logging tracked with the read-access work |
Read-access logging is expanding
If your compliance program requires a who-viewed-whom trail for every read (a common expectation for tools handling employment-decision data), request current status from your account team. Administrative and mutating actions are logged today; comprehensive read-access logging is the active roadmap item, and the data model (action/resource_type/resource_id/user_id) already supports it without schema change.
Retention¶
Audit logs are retained for 7 years by default under the platform's data-retention policy (legal basis: legal obligation and legitimate interest), independently of the shorter operational retention for raw request telemetry. Retention is enforced automatically and the enforcement run is itself audited. See Data retention and erasure.
Because audit logs are treated as evidence, the right-to-erasure workflow anonymizes rather than deletes audit entries where deletion would defeat the record's legal purpose — see Data retention and erasure.
Accessing the audit trail¶
- Data-subject export. A candidate's own audit history is included in their data export package (
_export_audit_data), so an access request returns not just profile data but the activity log associated with them. - Organization export. Organization admins can export their organization's data, which includes the audit logs scoped to that organization (see Organization administration).
- Investigations / on request. For incident response or a regulator inquiry, SkillFoundry can produce a filtered audit extract (by actor, action, resource, or time window) under the terms of the DPA.
Integrity and tamper-resistance¶
- No public API mutates or deletes individual audit records; deletion happens only through time-based retention enforcement or erasure anonymization, both of which are themselves audited.
- Backups of the audit collection are captured in the encrypted, checksum-verified, cross-region backup process (see Certifications and attestations), so the trail survives a primary-store incident.
- Roadmap: cryptographic hash-chaining / write-once storage for the audit collection to provide mathematical tamper-evidence, and streaming export to a customer-owned SIEM.