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.4 · reviewed 4 October 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.
Two-step sign-in. A code from an authenticator app as well as the password. Anyone can turn it on, administrators can require it for their team, and wrong codes lock the account like wrong passwords.
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 comes from the connection itself. The web server accepts a forwarded address only from our own load balancer on its private network, and takes the address the load balancer itself saw, so a value a client adds to the header is ignored.
Recovery codes. Each user with two-step sign-in has one-time recovery codes for a lost phone, stored as one-way hashes, and an administrator can reset two-step sign-in for a user who has lost both.
Security watch. Every hour our systems look across all workspaces for signs of attack: repeated failed sign-ins, many accounts tried from one address, wrong two-step codes, locked accounts, IP-allowlist refusals and a sign-in from a new country. The country is looked up on our own servers; no address is sent to a third party. Each finding opens an incident for our team to review, and nothing is decided automatically.
Data hosting location
Xinnace’s application servers, databases (one for each customer), session cache and uploaded documents are hosted in South Africa, on Amazon Web Services in its Cape Town region (af-south-1), all encrypted at rest. Backups are held in the same 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 through Google and, only when someone uses them, YouTube help videos, Giphy and Google sign-in, process data outside South Africa. Fonts and interface code are served from our own servers. Where that happens we require an adequate level of protection, as POPIA expects.
Other regions. We are preparing hosting in London, Ireland and North Virginia for customers who need their data kept there. When a region opens, that customer’s databases, documents and backups stay in it; until then, all customer data is in Cape Town.
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, everything we store is encrypted at rest, 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. Inside our network, the servers reach the session cache over TLS too.
At rest. Every place your data is stored is encrypted at rest with AES-256, using keys AWS manages and never hands out: the databases, the session cache, the shared storage for uploaded documents, the servers’ own disks, and the nightly backups. A disk or backup file taken away from AWS cannot be read.
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, wrong two-step codes, lockouts, IP-allowlist refusals, permission denials and settings changes are recorded separately from data changes, so an investigation does not have to sift through routine edits.
IP addresses on your clock. You choose how long logs keep IP addresses and browser details (3, 6, 12, 24 or 36 months, or for the life of the workspace); a nightly job clears older ones and leaves the record of what was done.
ID numbers masked. An employee’s ID number is held in full only on their record; the audit trail and history store and show the last four characters.
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 to storage in South Africa (AWS Cape Town), where they are encrypted at rest, public access is blocked, each night is stored as a separate dated copy, and copies expire on their retention schedule, normally within 90 days. The credentials the servers carry cannot delete backups. They can add a backup and read it back to verify a restore, and an overwritten backup remains recoverable for 30 days, so an attacker who takes a server cannot destroy the history behind it. The database service also keeps its own automated backups for 7 days, with point-in-time recovery, and each night one workspace’s backup is restored into a scratch database to prove the copies work. Backup retention, recovery requirements and any customer-specific continuity needs are confirmed during onboarding.
Tested, not promised. On 4 October 2026 we restored the production database to a separate copy, checked it against the live one in every workspace, and opened the newest uploads backup. Measured: about 5 minutes of database data at risk (point-in-time recovery) and about 10 minutes to a working database at today’s size. Uploaded documents are backed up nightly, so up to about a day. One test, not yet on a schedule; we will not quote figures we have not measured.
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. Race, disability and gender can each be switched off for a workspace, after which they are not asked, shown, exported or sent through the API.
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 on return-to-work files and on leave applications each have their own workspace setting that switches them off, after which the server refuses them. Copies that are kept are held in private storage that the web server refuses to serve directly, are never served inline, and are released only through a permission-checked download, to a permitted user whose access to that employee is re-checked on the request.
Requests and deletion. A register tracks every privacy request against its one-month deadline, and an employee’s subject access file is produced in one step. Recruitment records can be erased under section 24, with uploaded CVs and ID copies removed from storage before the record itself. An employee can be erased too: only what the BCEA and the Tax Administration Act still require is kept, and it is deleted when that period ends. You can also have leavers deleted automatically once their statutory period ends, each listed for 30 days first.
Registered and recorded. Our Information Officer is registered with the Information Regulator (2026-062328), and security incidents are recorded in an incident log with the Information Officer’s decision on notification.
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. Independent penetration testing (an internal penetration test by our own developer was run on 18 September 2026 and its findings fixed), 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 scheduled. Restore testing has been done and documented once (4 October 2026, figures above). It is not yet on a regular schedule.
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”.