Security posture
Trust is part of the product, not an afterthought.
TALZA handles candidate data, employer intent and commercial hiring events. The platform is built around consent, restricted visibility, moderation and auditability from the ground up.
Privacy-by-design architecture
Candidate consent centre, anonymous browse, admin approval, PII encryption at rest, salted ID-number hashing, rate limiting, audit trail and consent-gated identity release are integrated into every workflow.
Privacy-by-design
Employer browse never exposes candidate names, emails, phone numbers or exact addresses. Identity is released only through the consent-gated introduction process, controlled by the candidate.
Admin moderation gate
Every candidate profile is reviewed and approved by a TALZA administrator before it becomes visible to employers. Profiles can be hidden, rejected or flagged for changes at any time.
Immutable audit trail
All sensitive platform events, including consent changes, identity releases, profile access, admin actions and introduction activity, are logged with timestamps. Audit records support dispute resolution, compliance review and operational integrity.
Technical controls
How candidate data is protected
Encryption at rest (AES-256-GCM): all personally identifiable information is encrypted using AES-256-GCM before it is written to the database. Decryption requires server-side keys that are not accessible from the client or database layer.
ID number hashing (SHA-256): South African ID numbers are validated using checksum verification and stored only as salted SHA-256 hashes. The original ID number cannot be recovered from the hash.
Password hashing (PBKDF2): account passwords are hashed using PBKDF2 with unique salts and high iteration counts. Plaintext passwords are never stored or logged.
Token security: session and authentication tokens are generated using cryptographically secure methods and hashed with SHA-256 for storage.
Consent-gated identity release: candidate names and contact details are encrypted separately and only decrypted and shared with a specific employer after the candidate explicitly accepts an introduction request. This is enforced at the application layer and recorded in the audit trail.
Infrastructure and edge security
TALZA is deployed on the Cloudflare global network, providing:
DDoS protection: automatic mitigation of volumetric and application-layer attacks at the edge.
TLS everywhere: all connections are encrypted in transit using TLS 1.2 or higher.
Web Application Firewall: managed rulesets filter common attack patterns before they reach the application.
Edge caching: static assets are served from the nearest Cloudflare point of presence, reducing origin exposure.
Application security
Security headers: responses include HSTS (Strict-Transport-Security), X-Frame-Options (DENY), X-Content-Type-Options (nosniff), Referrer-Policy and Content-Security-Policy headers to protect against common web vulnerabilities.
Rate limiting: API endpoints and authentication routes are rate-limited to prevent brute-force attacks and abuse.
Input validation: all user input is validated and sanitised before processing. SA ID numbers are checked against the Luhn checksum algorithm before acceptance.
Error handling: error responses do not leak internal system details, stack traces or database information.
Responsible disclosure
If you discover a security vulnerability in the TALZA platform, please report it responsibly by emailing contact@talza.co.za with a description of the issue and steps to reproduce it. We take all reports seriously, will acknowledge receipt promptly, and will work to resolve confirmed vulnerabilities as quickly as possible. We ask that you do not publicly disclose the vulnerability until we have had a reasonable opportunity to address it.