Short answer.
SealTask can coordinate approved next actions around recruiting and people operations without becoming a second employee or candidate record. Keep identity, notes, decisions, payroll, medical information, and case evidence in the ATS, HRIS, payroll, or restricted case system. Encrypted task content still has server-visible operational metadata.
Why not keep every follow-up in the ATS or HRIS?
Sometimes you should. But cross-functional work also spans hiring managers, interview panels, IT, payroll, legal, facilities, and external recruiters. The coordination layer often falls back to email or a general task app.
Candidate identity travels farther than the candidate record.
A task title can reveal a person’s application, role, offer status, accommodation, background check, or internal mobility before anyone opens a profile.
Hiring teams need different slices of context.
An interviewer may need a preparation task. Payroll may need an onboarding handoff. Neither necessarily needs the recruiter’s complete pipeline or another employee’s case list.
Retention and deletion remain system responsibilities.
An encrypted duplicate is still a duplicate. Copying resumes, medical information, reports, or scorecards into tasks complicates retention, access requests, and deletion workflows.
Does end-to-end encryption hide everything?
No. SealTask cannot decrypt readable workspace content, but the service still operates on account and task metadata.
Unreadable to the service
- Readable task titles
- Readable task bodies and notes
- Readable recurring-task template content
- Readable comment bodies
- Readable checklist content
- Readable project titles and descriptions
- Attachment plaintext
- Plaintext account passwords
- Workspace content decryption keys
Server-visible workspace metadata
- Account email addresses and workspace or project membership identities, roles, statuses, invitation states, and access timestamps
- Database identifiers and relationships, including project owner, task and note creators, comment authors, delegation members, attachment uploaders, and per-member task-read cursors
- Project timezone, section identifiers and policies, section timestamps, and task position or order
- Task priority, completion and archive state and timing; note privacy and timestamps; per-member task-read timestamps; project timestamps and archive state; note, comment, and attention counts; and workspace write or collaboration entitlement flags
- Recurrence schedule, timezone, active state, section, iteration, next-run, last-materialized, and task-materialization timestamps
- Comment authorship relationships, counts, and timestamps; comment bodies remain encrypted
- Delegation membership identifiers, roles, statuses, and timestamps; delegation notes remain encrypted
- Attachment, project, and task relationships, including task-to-attachment link timestamps; storage identifiers; ciphertext byte size (which usually approximates original file size); upload capability expiry and protocol; status; and creation, update, or deletion timestamps; attachment content remains encrypted
- Per-membership salts and membership proofs, plus the server-held project-scoped payload-binding key used to verify or compute matching HMACs; this binding key is not a workspace-content decryption key
- Real-time event types; event, project, actor, membership, browser-instance, affected entity, section, and order identifiers; changed-field names; occurrence timestamps; and missed-event counts
This disclosure covers encrypted workspace content and its server-visible metadata. The workspace-content metadata inventory is complete for the enumerated current workspace persistence and SQL models, API-response models, and SSE event models. It is not a complete privacy-data inventory and excludes account authentication, billing, security and audit, abuse-prevention, and service telemetry domains; those domains are described non-exhaustively in the privacy policy. Metadata can itself be sensitive. Attachment ciphertext size usually reveals an approximation of the original file size.
A due date can imply an offer deadline, leave event, investigation milestone, or termination date. Keep sensitive timing in the ATS, HRIS, or case system when metadata itself would disclose too much.
Inspect the security architectureWhat does a minimized hiring workflow look like?
Role R-42 has reached final interviews. The task layer carries ownership; the ATS carries the candidate record.
SealTask
R-42: confirm final-panel availability.
The role reference, next action, and owner are enough for operational coordination.
SealTask
R-42: remind hiring owner to record decision.
The reminder lives in SealTask; the actual decision and rationale do not.
Specialist system
Candidate identity, resume, interview notes, and scorecard.
These remain in the ATS with its retention and candidate-rights workflow.
Specialist system
Background report, health information, or accommodation detail.
Keep sensitive or special-category information in the specifically approved restricted system.
Data minimization is not achieved by encrypting a large duplicate. It starts by not creating the duplicate.
Where should each kind of people work live?
This table assumes the organization has approved SealTask as a coordination tool. Law, policy, works-council obligations, and contracts may require a different answer.
| Work item | SealTask | System of record | Why |
|---|---|---|---|
| Role-level owner and interview scheduling prompt | Yes — use neutral references | ATS and calendar | The task coordinates; candidate communications and status stay authoritative in the ATS. |
| Resume, interview notes, scorecard, offer record | No — do not duplicate | ATS | Candidate records need retention, access, correction, and deletion handling in one place. |
| Payroll, tax, benefits, identity, and bank data | No | HRIS, payroll, and benefits systems | These systems own restricted processing and authoritative records. |
| Investigation, grievance, medical, or accommodation detail | Neutral reminder at most | Restricted HR case or health-record system | High-sensitivity case material needs separate access and legal handling. |
| Onboarding checklist across departments | Yes — scoped shared list | HRIS and department systems | The list aligns owners while formal employee data remains elsewhere. |
Which HR workflows fit a private task layer?
The answer depends on whether the task is a coordination prompt or the person record itself.
-
01 · Recruiting
Move a role through interviews.
Use role and candidate references for scheduling, owner follow-up, and panel readiness. Keep resumes, notes, ratings, and candidate communications in the ATS.
ExampleRole R-42: confirm final-panel availability.
-
02 · Onboarding
Coordinate the first-day sequence.
Track equipment, account, orientation, and manager actions. Keep identity, payroll, tax, benefits, and right-to-work documents in approved HR systems.
ExampleNew starter S-18: verify equipment owner.
-
03 · People operations
Repeat policy and access reviews.
Use recurring tasks for handbook and process checks. For fixed-term access, optionally choose an access-end date when inviting; leave it unset when policy calls for manual removal. At each recertification, open Access review to see each person’s projects and last-active date, then remove a leaver across every project you manage. Review source-system access separately and store evidence where policy requires.
ExampleQuarterly: review leaver-access checklist completion.
-
04 · Sensitive casework
Coordinate without reproducing the case.
A neutral case reference and next action may be appropriate after policy review. Allegations, medical details, investigation notes, evidence, and decisions belong in the restricted case system.
ExampleCase P-09: confirm next-review owner.
What does SealTask add that an ordinary checklist does not?
Encrypted content, narrow list sharing, revocation, recurring work, and private search reduce the readable coordination trail. They do not replace HR governance.
Recurring tasks without recurring plaintext
Set repeating operational work once. The task content stays encrypted on the client before sync; due dates and recurrence timing remain operational metadata.
One shared list, not blanket access
Personal (€5.90/month) adds per-list sharing. Invite a collaborator only to the list they need. Removing a collaborator revokes their server-authorized access to the project. Using access review to remove them from every manageable project applies that same server-side revocation to each project. On the server that commits the change, active real-time streams are signaled after the commit; changes committed on another server and bulk or otherwise unsignaled changes are rechecked within the current authorization lease, at most 30 seconds. Bytes already delivered or buffered by the transport cannot be recalled. The current release does not automatically rotate any affected project key or re-encrypt projects for remaining members, and removal cannot erase content or key material obtained while the collaborator was authorized. If future sensitive work needs a fresh cryptographic boundary, create a new project and share it only with current members.
Private search on the device
Search runs after local decryption in the browser. SealTask does not need a readable server-side search index of workspace content.
A €0 solo starting point
Free includes one workspace, two projects, 100 MB of encrypted attachments, and 30-day audit history. No credit card is required.
Is SealTask an ATS, HRIS, payroll system, or case file?
No. SealTask does not provide candidate consent workflows, automated-decision controls, subject-access fulfillment, legal retention schedules, payroll, benefits administration, background checks, medical-record segregation, works-council tooling, or formal HR case management.
SealTask is not currently SOC 2 certified; accounts can add optional authenticator-app two-factor authentication (TOTP) with one-time backup codes. Organizations should assess contracts, lawful bases, processor terms, international transfers, device controls, access reviews, retention, incident response, and worker or candidate notices before use.
Encryption protects content against readable server access. It does not prevent an authorized hiring manager from copying content or fix an over-broad sharing decision.
Questions this guide should answer.
Can recruiters put candidate names in SealTask?
The encrypted content would not be readable to SealTask, but your organization must still decide whether doing so is lawful, necessary, disclosed, and consistent with policy. A neutral ATS reference often minimizes duplication.
Can SealTask replace an ATS?
No. The ATS should remain authoritative for candidate identity, communications, notes, decisions, consent, retention, and rights handling. SealTask can coordinate approved next actions around it.
What HR information remains visible as metadata?
SealTask cannot decrypt readable task, project, note, comment, checklist, recurring-template, or attachment content, and it does not receive plaintext passwords or workspace content keys. The service can still see operational metadata such as account and membership identities, relationships, task state and timing, recurrence schedules, attachment sizes and statuses, and real-time event identifiers. Metadata can itself be sensitive; the security architecture lists the complete current workspace inventory.
Should medical or background-check information go in a task?
No. Keep it in the specifically approved restricted system. A neutral reminder may still reveal timing or case status through metadata, so assess that separately.
Does SealTask automate hiring decisions with AI?
No. SealTask has no AI feature that analyzes workspace content and is not an applicant-ranking or automated-decision system.
Sources and further reading.
- 01
SealTask security architecture Open page Encryption, key handling, server visibility, and recovery tradeoffs
- 02
SealTask pricing Open page Current Free, Personal, Team, and self-hosted terms
- 03
Best encrypted task management Open page A source-backed comparison of encryption models and product tradeoffs
- 04
ICO — Recruitment and selection guidance Open source Draft guidance for employers, recruiters, agencies, head-hunters, and consultancies; consultation closed and final guidance is pending
- 05
ICO — Keeping employment records Open source Guidance on collecting, using, securing, sharing, and retaining worker records
- 06
ICO — Data minimisation Open source Personal data should be adequate, relevant, and limited to what is necessary
- 07
EUR-Lex — Regulation (EU) 2016/679, Article 5(1)(c) Open source Official GDPR text supporting that personal data be adequate, relevant, and limited to what is necessary
- 08
EEOC and FTC — Background checks: what employers need to know Open source US federal guidance on employment decisions, recordkeeping, FCRA procedures, and secure disposal
Coordinate the work without cloning the person record.
Start with a private Free workspace. Before inviting a hiring team, define the allowed task content and the systems that remain authoritative.