HR data is the most sensitive data most businesses hold: ID numbers, salaries,
disciplinary records, health-related absence information. This page sets out how
Xinnace is built to protect it, in plain language and without marketing gloss. It
describes controls that are in place today rather than plans, it says plainly where
a control is not yet in place, and we are happy to walk your IT or legal team
through any of it.
Local hosting
Tenant isolation
TLS encryption
Role-based access
Audit logging
Version 1.1 · reviewed 10 September 2026
How the platform is built
Controls that ship with the product, not configured per customer.
Security is built into multiple layers of Xinnace, including the application, database, server configuration and hosting environment. Application-level controls are deployed consistently with the platform and supported by infrastructure-level protections.
Security overview
Tenant isolation. Every customer gets their own separate database. The lookup that maps a workspace to its database is designed to fail closed: an unknown or suspended workspace is refused rather than falling back to another customer’s data.
Enforced HTTPS. HTTP Strict Transport Security is sent with a one-year lifetime covering workspace subdomains, which instructs browsers to refuse a plain HTTP connection before it is made.
Brute-force protection. Sign-in attempts are rate limited per IP address, and repeated failures are locked out for a cooling-off period.
Session hardening. Session cookies are HTTP-only, secure and SameSite-restricted, and the session identifier is regenerated on sign-in, which closes off session fixation.
Browser-level protections. Clickjacking, MIME-sniffing, injected base tags and off-site form posting are blocked by response headers applied across authenticated platform routes, not only on static files.
Forged-header defence. The IP address written to the audit trail starts from the connection itself, which the server sets and a client cannot forge. A proxy header is read only when the connection arrives from a recognised Cloudflare range; the X-Forwarded-For header is not used, because any client can send one.
Data hosting location
Xinnace’s primary application, databases and uploaded documents are hosted on a dedicated server in a South African data centre, provided by Afrihost. Off-site backups are held in South Africa too, in the AWS Cape Town region. Certain supporting services may process limited information outside South Africa, as explained in our Privacy Policy.
Local hosting means local latency: the platform is fast for South African users rather than fast for someone else’s users.
Keeping primary personal information in South Africa reduces the cross-border transfer questions that offshore platforms have to answer under POPIA.
A small number of supporting services, notably email delivery through Google, process data outside South Africa. Where that happens we require an adequate level of protection, as POPIA expects.
If your assessment needs the full picture, including where each set of backups is held and which supporting services are involved, ask us and we will set it out for your file. Our Privacy Policy covers the processing side.
Encryption
Traffic between your browser and Xinnace is encrypted in transit using HTTPS and TLS, and passwords are not stored in a form we or anyone else can read back.
In transit. Connections use HTTPS with TLS. Plain HTTP is refused rather than redirected, across the platform and its workspace subdomains.
Passwords. Passwords are never stored in plain text. They are stored as salted bcrypt hashes, which helps protect credentials if database information is ever exposed. Xinnace staff cannot retrieve a password, only trigger a reset.
Password strength still matters. Hashing protects a stored credential; it does not make a weak password safe. Set a password policy your organisation is comfortable with, and use the optional IP restriction below if your policy calls for it.
API access. Integration keys are stored hashed, carry only the specific scopes you grant them, and are individually rate limited and revocable.
Roles and permission controls
Access is granted by role, and roles are yours to shape. Modules, screens and actions are designed to be reachable only by the roles you have granted them to.
Fully customisable roles. Start from a catalogue of ready-made roles covering the usual HR, payroll, line-manager and employee patterns, then change them, or build your own from scratch.
Granular permissions. Rights are set per action, not per module, so viewing, adding, editing and deleting are separate decisions. A manager can be allowed to view attendance without being able to change it.
Enforced server-side. Permissions are checked on the request, not just in the interface. Hiding a menu item is a convenience; the check that matters happens before any data is returned.
Protected administrator role. The super administrator role cannot be deleted or stripped of its rights, so a workspace cannot be locked out of its own account.
Xinnace staff access. When support needs to see your workspace, entry is through a single-use, short-lived token, it is recorded on both our audit trail and yours, and a banner is shown for as long as the session lasts.
Optional IP restriction. Sign-in can be limited to your office IP ranges where your policy requires it.
Running it day to day
Evidence, continuity and privacy.
Audit logging
Changes to people data are recorded as a matter of course, which is what turns “we think that was corrected in March” into evidence.
Before and after. Record changes are logged with both the previous and the new values, alongside who made the change, from where, and when.
Security events too. Failed sign-ins, permission denials and settings changes are recorded separately from data changes, so an investigation does not have to sift through routine edits.
Written in the application. Audit entries are written by the code performing the change rather than by database triggers, which keeps the logic visible, testable and in one place.
Useful well beyond security: disciplinary matters, CCMA disputes and payroll queries all turn on being able to show exactly what changed and when.
Backups and continuity
Databases and uploaded documents are backed up nightly. Each backup is encrypted on the server before it leaves it, then copied to off-site storage in South Africa (AWS Cape Town), where public access is blocked, each night is stored as a separate dated copy, and copies are held for 90 days. The credential the server carries can write to that storage and do nothing else. It cannot list, read or delete what it has already written, so an attacker who takes the server cannot read the backups or destroy the history behind them, and the key that would decrypt them is not on the server either. A fortnight of nightly copies, and six monthly ones, are also kept on the server itself for fast recovery. Server-level backups are additionally managed by Afrihost as part of our dedicated hosting. Backup retention, recovery requirements and any customer-specific continuity needs are confirmed during onboarding.
What we will not do. Quote a recovery time or recovery point objective we have not tested. When scheduled restore testing is in place, the verified figures will be published here rather than described in general terms.
Keep your own copy. The main registers, including employees, attendance, payroll and recruitment, export to CSV, and our REST API lets you pull your data on your own schedule. An export you hold yourself is the backup you control.
No lock-in. Your data is yours. You can cancel on 30 days’ notice, and if you leave, you can take a full export with you.
If your organisation has a specific retention or recovery-time requirement, raise it before you sign and we will tell you plainly whether we can meet it.
Privacy and POPIA
Xinnace is designed with POPIA principles in mind, and the roles are set out clearly so there is no confusion about who is accountable for what.
You remain in control. For the employee data you put into Xinnace, your organisation is the Responsible Party and Xinnace is your Operator. We process it on your instructions and not for our own purposes.
Consent where it is needed. The public-facing forms, job applications and referrals capture explicit consent before collecting personal information.
Special personal information. Fields such as race and disability status, needed for Employment Equity reporting, are recognised as special personal information and handled accordingly.
Health information you need not store. Sick absence is health information and a medical certificate is the sharpest form of it. A return-to-work file can record that a certificate was produced and checked — practitioner, registration number, the days it books off — with no copy uploaded, and certificate uploads can be switched off for the whole workspace, after which the server refuses them. Copies that are kept live outside the web root and are released only to a permitted user whose access to that employee is re-checked on the request.
Deletion requests. Recruitment records can be erased on request under section 24, with uploaded CVs and ID copies removed from storage before the record itself, so a deletion cannot leave documents stranded on disk. Employee records stay on their statutory clocks under the BCEA and the Tax Administration Act, which are not the data subject’s to waive.
Read the detail in our Privacy Policy, or see how to make a records request under PAIA.
Support arrangements
You deal with the people who build the platform. There is no offshore first line reading from a script.
How to reach us. Email support@xinnace.com. We aim to respond within one business day.
Onboarding. New workspaces are set up with you, not handed over with a login and a link to the manual.
Everything described above is something we can show you on request. The controls we do not yet have are named here rather than softened into a claim.
Assurance, and what is not in place yet
Xinnace is not currently ISO 27001 certified. Our security controls are being developed with recognised information-security practices in mind, and the honest position on the rest is set out below.
Not yet in place. Multi-factor authentication, independent penetration testing, scheduled vulnerability scanning and a published patch cadence. These are on the roadmap and we would rather name them than imply a control we cannot demonstrate.
Not yet formally tested. Restore testing, against either our own off-site backups or Afrihost’s server-level ones. That the backups run, and that each night is written and retained, we can show you. What we have not yet done is a documented restore from them, so we will not publish recovery figures until that is scheduled and evidenced.
What this page is. A description of controls we can show you, not a certification. If an item here matters to your assessment, ask for a demonstration and we will arrange one.
Where we are strong. Tenant isolation, server-side permission enforcement, audit coverage and local hosting are built in rather than configured per customer, so they hold consistently across every workspace.
Reporting a security issue
Tell us directly and we will treat it as a security matter, not a sales enquiry. Security correspondence has its own address, kept separate from sales.
Contact. To report a suspected security issue or request technical security information, email security@xinnace.com. We aim to acknowledge within one business day.
What helps. The affected URL or workspace, what you did, what you observed, and roughly when. A reproduction beats a scanner summary.
Please do not. Include employee or candidate personal information in the report, run load or denial-of-service testing, or access data belonging to another workspace to prove a point. Tell us what you found and we will verify it ourselves.
Good faith. We will not pursue a reporter who investigates responsibly, tells us first, and gives us reasonable time to fix the issue.
Need more detail?
Security questionnaires, vendor assessments and due-diligence packs are part of the job, not an imposition. Send yours through and we will complete it properly, including the questions where the answer is “not yet”.