How Your Data Is Protected The layers between your data and everyone else's: tenant isolation, row-level rules, encryption, and what each one actually covers.

This is what protects your data, described accurately rather than reassuringly. Some of it is ours; some of it is yours to configure.

Tenant Isolation

Every record carries the organisation it belongs to, and access is enforced in the database rather than in the application.

That distinction is the whole point. Rules enforced in application code protect you from the application's own bugs only as long as every query remembers to apply them. Rules enforced in the database apply to every query, including ones written later by someone who did not know the rule existed.

Row-Level Rules

Beyond the organisation boundary, access narrows by role and by hub. Two people in the same organisation see different rows, decided by the same database-level rules rather than by what the screen chooses to render.

This is why hiding something in the interface is never how access is restricted here - see Permissions in the Settings section.

Encryption

Data is encrypted in transit, and specific sensitive fields are additionally encrypted at rest, separately from the record they belong to:

• Dates of birth, passport numbers and national identity numbers
• Bank details and account numbers
• Emergency contacts
• Dependants' names and dates of birth
• Candidate CVs

The encryption key version is recorded with the data, so keys can be rotated without losing the ability to read what was written under a previous one.

Who Can See What Is Your Decision

The platform enforces the boundaries; you decide where they sit.

Seeing the employee directory and seeing a passport number are separate permissions. So are seeing a deal and seeing its value. If everyone in your workspace can see everything, that is a configuration choice rather than a limitation. See Permissions.

Sign-In

Multi-factor authentication, session timeouts and heightened protection are all enforced. The policy is set per workspace by NearSync, and you may raise the MFA requirement above that baseline but not below it. See Signing In Securely.

The Audit Trail

Changes are recorded at field level - who, when, and the before and after values. See The Audit Trail.

What We Do Not Do

Being straight about the boundaries:

• We do not read your data in the ordinary course. Support access to a workspace is by request and by arrangement, not standing.
• We do not hold your card details. The payment provider does.
• We cannot recover an encrypted field for you if the key material is lost on a self-hosted deployment - that is the trade you accept by holding your own infrastructure.

Your Half

The controls that matter most are usually the ones on your side:

1. Require MFA. The single highest-value change most workspaces can make.
2. Grant the narrowest role that works, and review it when people change job.
3. Remove access on the last day, not the following week.
4. Watch the audit log after anything unusual.
5. Treat exports as live data - they leave every one of these protections behind.

Common Questions

Where is our data physically? Depends on your deployment. See Where Your Data Lives.

Can NearSync staff see our records? Not routinely. Access for support is arranged with you.

Is it encrypted? In transit, yes. At rest, the sensitive fields listed above are additionally encrypted with a recorded key version.

Do you have a certification? Ask us for the current position rather than relying on a help page - certifications have dates and scopes, and a page like this goes stale.