Security
Locked tight. Explained simply.
A friendly tour of everything we do to keep your work safe — encryption on every connection, doors that only open for the right people, and an honest note about limits. No jargon walls. No fine-print tricks.
- HTTPS everywhere
- TLS encryption
- Server-side authorization
- Private by default
Locked by default
Private means private. Every record starts closed until you open it.
Encrypted in transit
Your data travels sealed in modern TLS encryption — like a locked envelope, every time.
Your data, your rules
You own your information. We guard it, and we never sell or monetize it.
Encryption
Every connection. Encrypted. No exceptions.
From the moment you open our site to the moment a file lands in your hands, your information travels sealed — the same class of encryption banks rely on, on by default, always on.
HTTPS everywhere
Every page, every form, every click — the whole site runs over secure HTTPS.
TLS in transit
While your data moves between you and us, it is wrapped in modern TLS encryption.
Checked server-side
The friendly interface is just the surface — every request is verified behind the scenes.
Sealed file links
Private documents open only through short-lived signed links that expire fast.
We would rather over-protect than over-explain.
Identity
Everyone gets their own key — and only theirs.
Getting in always starts with signing in as you. No shared logins, no mystery guests.
One identity per person
Access to any workspace requires an authenticated account before any data is available.
Verified recovery
Account verification and password recovery are handled by the authentication layer — not guesswork.
Your profile is yours
Personal profiles live apart from organization data, and each person controls their own record.
Admin powers, held deliberately
Platform administration is separate from everyday roles and only granted on purpose.
Organization isolation
Your organization’s work stays in its own yard.
One organization can never peek into another — the walls are checked on the server, every single time.
Scoped records
Projects, tasks, files, and activity all belong to an organization — and requests are checked against it.
Membership required
Seeing an organization’s workspace requires an active membership in that specific organization.
No hints on denial
When access is not granted, the system responds without confirming that anyone else’s data exists.
Cross-organization checks
Operations that reach into another organization are validated and rejected server-side.
Role-aware access
People see what their job needs — nothing more.
Access is granted by role and membership, so nobody carries keys they do not need.
Platform roles
Platform-level roles separate standard users, Hermida staff, and platform administrators.
Organization roles
Inside an organization, roles (owner, admin, member, viewer) decide what a person may do.
Project access
Restricted projects require an explicitly granted, still-active access record.
Least privilege
Capabilities are handed out sparingly — only what someone’s responsibilities actually require.
Enforced behind the scenes
Authorization is evaluated on the server for every request — the interface is never the lock.
Protected data
Private means invisible from the outside.
Public surfaces never expose private records — here is exactly what that means.
- Protected routes are excluded from public discovery tools such as the sitemap and search metadata.
- Sensitive records are never included in public metadata, page titles, or structured data.
- Public forms cannot assign administrative fields — public intake is limited to defined, validated fields.
- Internal notes and administrative fields are never exposed through public pages or APIs.
Sensitive projects
The sensitive stuff needs a personal invite.
Restricted projects stay invisible until the right person is granted access — and that grant is re-checked constantly.
Explicit access records
Visibility requires a ProjectAccess record granted by an authorized person — nothing is assumed.
Membership still required
An access grant alone is not enough; the person must also hold an active membership in the project’s organization.
Organization matching
The access record must belong to the same organization as the project; mismatches are rejected.
Checked on every request
Every project read and action is authorized on the server before any data is returned.
Input validation
Bad data gets stopped at the door.
Nothing is stored or accepted until it has been checked — quietly, on the server.
Cleaned and checked
Incoming values are normalized and type-checked before they ever reach stored records.
Only expected fields
Just the fields we asked for are accepted; anything unexpected is turned away.
Sensible lifecycles
Status transitions follow defined rules, so records cannot move into invalid states.
Cross-record integrity
References between records are checked for existence, organization match, and authorization.
Friendly, neutral errors
Public error messages explain the next step without exposing internals.
Responsible disclosure
Spot something odd? Tell us — we’ll actually listen.
If you believe you have found a security issue involving a Hermida Technologies system, we want to hear from you. Reach us through the contact page and leave sensitive exploit details out of the first message. We take every report seriously.
Our honest fine print
Security is a practice — not a promise sticker.
No online system can honestly be called risk-free. Security is an ongoing engineering practice, and what it means for your implementation depends on hosting, integrations, configuration, and day-to-day operations. We would rather tell you that plainly than pretend otherwise.
Still curious how it all works?
Ask us anything about how your organization’s data is protected — we genuinely love these questions.