Stage 01
Collect
Category, subject, source, necessity, validation.
Is this necessary for the stated purpose?
Privacy
Make workforce-data use visible, limited, and reviewable
What categories are collected and from which sources, for what purpose, who can access or receive them, how long they are kept, where they are processed — and how the person a record describes can see it, understand it, and ask for it to be corrected.
Truth boundary
A privacy statement is valid only within its stated role, data category, purpose, customer configuration, product scope, region, date, and limitation. Technical capability never creates permission by itself.
Time evidence without hidden surveillance
No screenshots, keystroke content, URL history, application-name monitoring, or clipboard collection under any tier or configuration.
Time entries, schedules, approvals, presence context, and evidence records describe work against configured policy. Invasive productivity monitoring describes a person using a device. These are different categories of data, and ZoikoTime collects only the first.
Commitment owner: Trust & Governance · Status: Current · Last reviewed 12 Jul 2026 · Next review 12 Jan 2027
Workforce-Data Lifecycle
Six Stages, Each With a Governing Question
This diagram is not a claim that every category follows the same schedule or basis — different categories diverge at almost every stage.
Stage 02
Use
Purpose, policy, context, rule version.
Is any secondary use prohibited here?
Stage 03
Share
Recipient, role, authority, scope, transfer, contract.
Who receives it, and under what authority?
Stage 04
Store
Environment, location class, tenant separation, protection.
Where does it live, and how is it bounded?
Stage 05
Retain
Schedule, trigger, owner, legal hold, review.
What ends this, and who owns that decision?
Stage 06
Delete or preserve
Deletion, anonymization, archive, export, hold, evidence.
What actually happened, and what proves it?
Deletion is not instantaneous or universal
Deletion, anonymization, archive expiry, backup expiry, and legal hold are distinct outcomes with distinct timelines. Legal holds and security records are not silently removed by an ordinary user deletion, and no page on this site claims data is "deleted everywhere immediately."
Data Categories & Sources
Six Categories — and What Each One Must Never Imply
The third column matters as much as the second. Most privacy harm comes from a category being read as more than it is.
| Category | Illustrative contents | Approved purposes | Never implies |
|---|---|---|---|
| Account & identity | Name, work email, account ID, authentication and role context. | Account access, identity, permissions, support, security. | That identity data determines employment status or legal authority. |
| Organization & configuration | Entities, teams, groups, roles, policies, schedules, integrations. | Administration, scope, workflow and reporting context. | That customer configuration creates legal permission. |
| Time & workforce records | Time entries, attendance and presence context, timesheets, breaks, approvals, exceptions, corrections where enabled. | Create, review, approve, preserve and report governed records. | Screenshots, keystroke content, URL history, application names, or clipboard content — none of which is ever collected. |
| Device & service metadata | Device and app version, timestamps, sync, security and diagnostic metadata where approved. | Service operation, security, troubleshooting, reliability. | Covert productivity monitoring or unrestricted location tracking. |
| Integration & provider records | External IDs, events, sync status, imported and exported records, connector health. | Authorized data exchange, reconciliation, recovery. | That every connector receives all data, or acts in the same privacy role. |
| Support, audit & incident | Support requests, change history, access and audit events, incident context. | Support, accountability, security, dispute resolution, legal and contractual needs. | That all message content or sensitive attachments are required. |
Purposes, Roles & Authority
Who Decides, Who Processes, Who Reviews
Your organization
- Defines permitted purposes and the instructions we act on
- Assigns roles and configures policy
- Issues worker notices and handles consultation duties
- Sets retention within product and legal constraints
- Holds the lawful and contractual context
ZoikoTime
- Processes authorized data within configured scope
- Applies product and security controls
- Supports worker visibility and correction routes
- Preserves evidence and change history
- States limitations rather than assuming permission
Workers & providers
- Workers see permitted context and receive applicable notices
- Workers use correction and review routes
- Connected providers act under their own or customer-approved roles
- The exact provider relationship is contract-specific
Two things this model does not do
It does not make your employment or legal decisions compliant — ZoikoTime cannot do that for you. And it does not transfer your responsibilities onto workers through obscure consent language. Controller and processor terminology appears only where the applicable contract and jurisdiction support it, not as decoration.
Worker Visibility, Explanation & Correction
Privacy, Made Operational for the Person in the Record
A right you cannot exercise from inside the product is not a right. Workers can see the record, understand why it says what it says, and ask a person to look again.
Step 01
See the record
Permitted record, source, timestamp, status, and relevant history.
Step 02
Understand it
Policy and rule context, the deterministic classification applied, and any pending-review state.
Step 03
Ask
Request a correction or an explanation, with a reason and supporting context.
Step 04
Human review
Routed to an authorized reviewer with status, due context, and an escalation path.
Step 05
Outcome preserved
Decision, change, source, and history recorded — without hiding the original record.
When the product view is not enough
An account or privacy request route exists for cases the in-product view cannot resolve. It does not require marketing consent, and it never has.
Privacy request routesWhat a flagged record is not
There is no automatic guilt or misconduct conclusion anywhere in this product. A record in review describes a record condition, not a person.
Honest limitation: correction rights and response obligations vary by role and jurisdiction. We describe the route clearly — we do not guarantee that every requested outcome will be granted.
Access, sharing & recipients
CurrentObjective: ensure only the right people and services can see or receive a record, for a stated purpose.
- Model
- Deny-by-default intersection of tenant, entity, role, team, record, purpose, and policy scope
- Separated
- Human access roles and service identities
- Distinct
- Internal access · customer-authorized access · provider access · public disclosure
- Audited
- Exports, APIs, webhooks, support access, and emergency access — each with specific authority, scope, time limit, and audit
Limitations: internal privileged architecture and restricted recipient detail are not published. Not every integration receives the same data, and connectors do not share a single privacy role — each is scoped separately.
Retention, deletion & legal hold
CurrentObjective: govern lifecycle endpoints so records neither persist without reason nor disappear without record.
- Schedules
- Record-type, purpose, customer, contract, and jurisdiction specific
- Triggers
- Account closure, record finalization, statutory period, support resolution, or configuration change where approved
- Distinct outcomes
- Deletion · anonymization · archive · backup expiry · legal hold
- Evidence
- Outcomes show scope, status, exceptions, and evidence. Superseded schedules preserve accountable history.
Limitations: there is no universal deletion deadline and no "deleted everywhere immediately" claim. Customer-configured retention cannot exceed product, contract, or legal constraints without review. Legal holds and security records survive ordinary user deletion by design.
Transfers, location & residency
Partially statedObjective: explain movement and location concepts without making promises this page cannot support.
- Distinguished
- Primary processing location · backup and DR location · support access · provider location · transfer mechanism
- Not determinative
- Your locale and user timezone do not determine data location
- Routed
- Customer-specific questions go to controlled Privacy Review
Limitations: no blanket "data stays in country" or "no international transfer" claim. Legal adequacy and transfer validity are never inferred from infrastructure region alone. Specific residency commitments belong to contracts and to the evidence-gated Data Location & Residency destination — which is not yet released and is therefore not linked here.
Automation, AI & Analytics Boundary
What Processes Your Data, and What It May Conclude
Deterministic classification
Policy-bound inputs and reviewable rules. It is not AI, and it is not described as AI anywhere in this product.
Approved machine learning
May flag anomalies or signal-quality concerns for human review. It does not decide anything.
Kairos
Retrieves, summarizes, and explains governed data within authorized scope. Decides nothing.
Public analytics
Privacy-minimized. Excludes worker-level content, search text, and sensitive intent.
Four claims absent by design
No automated employment, payroll, disciplinary, or legal decision. No hidden workforce scoring or behavioral profiling. No model-training claim — if training use ever exists, it will be described only with approved evidence. And no claim that AI is unbiased, compliant, or infallible.
Processors, Subprocessors & Integrations
Each connector is scoped separately
What a provider record states
- Data category and purpose
- Access scope and location class
- Contractual control and current status
- Authoritative detail route where current
Subprocessor summaries link to current authoritative sources where approved. Restricted recipient detail and provider terms are not exposed publicly. We do not present provider controls as ZoikoTime controls.
Privacy-Practices Directory
Six Practice Statuses, Applied Honestly
CurrentUnder reviewSupersededWithdrawnCustomer-specificEvidence-gated
TopicData categorySourcePurposeRoleAccess levelRecipient typeRetention classRegionStatusLast reviewed
Collection limits statement
PublicWhat is never collected, in every tier and configuration.
- Owner
- Trust & Governance
- Reviewed
- 12 Jul 2026
- Status
- Current
Limitation: describes non-collection. Not a compliance conclusion.
Data category & purpose map
PublicCategories, illustrative contents, approved purposes, and what each must never imply.
- Owner
- Privacy
- Reviewed
- 28 Jun 2026
- Status
- Current
Limitation: contents are illustrative, not an exhaustive field list.
Worker visibility & correction
PublicWhat a worker can see, ask, and escalate — and the limits of each.
- Owner
- Product governance
- Reviewed
- 04 Jul 2026
- Status
- Current
Limitation: available routes depend on your configuration and jurisdiction.
Retention schedule summary
Customer-specificSchedules by record type, trigger, and owner for your configuration.
- Owner
- Privacy
- Reviewed
- —
- Status
- Customer-specific
No public universal claim exists. Request through Privacy Review.
DPA & processing terms
ControlledCurrent contractual processing terms and their scope.
- Owner
- Legal
- Reviewed
- —
- Status
- Customer-specific
Terms depend on your agreement. Routed through controlled review.
Regional data location
ContractualProcessing and backup location classes assessed region by region.
- Owner
- Privacy
- Reviewed
- —
- Status
- Evidence-gated
The Data Location & Residency destination is not released, so it is not linked.
Withdrawn and superseded practices are excluded from default results and link to their current replacement. The search index excludes restricted and customer-specific content, and search terms are never captured in analytics.
Privacy Requests & Rights Routing
Six Request Types, and Who Answers Them
For most workforce-record questions your employer is the primary route, because they define the purpose and hold the context. We say so plainly rather than routing you in a circle.
Workforce-record explanation or correction
A question about a specific time, attendance, or approval record.
Primary route
Your authenticated personal record view, or the approved worker route with your employer.
Account access or correction
Your name, work email, or account details.
Primary route
Account settings, or the Help and Privacy route.
Customer-admin export or deletion
Organization-level export, deletion, or scope change.
Primary route
An authorized administrator, or Enterprise Support.
Privacy rights inquiry
Access, correction, deletion, restriction, objection, or portability questions.
Primary route
Privacy request route, with jurisdiction and relationship triage — and appropriate involvement of your employer.
DPA, subprocessor or transfer inquiry
Contractual and procurement evidence needs.
Primary route
Controlled Privacy Review, with secure evidence delivery.
Complaint or escalation
When a response was inadequate or a route did not work.
Primary route
Privacy or support escalation, with a named owner and a status path.
How requests are handled
- Identity and authority verification is proportionate and purpose-limited
- Status, clarification, partial fulfilment, exception, and appeal are all visible
- Exported data uses secure delivery with expiry, revocation, and audit
- Marketing consent is never required to submit a privacy request
Two things we will not promise
- A universal response time — obligations vary by jurisdiction and relationship
- That a specific legal right applies to you — that depends on your jurisdiction, your relationship to the data, and your employer's role
When submitting, do not include credentials, health information, union or representative details, legal strategy, or unnecessary worker data.
Privacy by design & change control
New or materially changed data use is reviewed before release: purpose, necessity, categories, roles, retention, worker impact, notice requirements, and evidence. A material change can require notice, reconsultation, or a blocked release under your governance rule.
Unsafe, stale, or factually unsupported privacy wording may be corrected or removed immediately, followed by a retrospective change record. We do not silently rewrite prior statements.
Privacy incidents & operational transparency
Privacy incidents follow a governed response with assessment, containment, notification criteria, and correction. Current service state — including operational incidents — is published on System Status, which is the authoritative source.
Not promised
Breach-notification obligations and timing depend on jurisdiction, contract, and assessed impact. No universal notification commitment is published here.
Direct Answers
Eight Privacy Questions
It collects account and identity data, organization configuration, time and workforce records, device and service metadata, integration records, and support, audit and incident records — each for stated purposes. It never collects screenshots, keystroke content, URL history, application-name monitoring, or clipboard content, under any tier or configuration.