Built for the teams that cannot move fast on security.
How IncentEdge stores, encrypts, and isolates your data. We hold no third-party security certification today, so what follows is a plain description of the controls that are actually in place, nothing more.
What happens to your data, technically.
This is what the platform does today. If a control your auditor needs is not listed here, it is not implemented yet. Ask us and we will tell you exactly where it stands.
Encryption
Traffic to IncentEdge is served over TLS. Data at rest sits on encrypted managed Postgres storage, and a set of sensitive identifiers is encrypted in the application before it is ever written to a row.
- In transitTLS
- At restAES-256
- Application-layer fieldsAES-256-GCM
- Encrypted identifiersEIN · DUNS · SAM UEI
- Webhook & API secretsEncrypted
Tenant isolation & access
Every customer table carries Postgres row-level security, so a query can only return rows belonging to the signed-in user's organization. Isolation is enforced by the database, not only by application code.
- Tenant isolationPostgres RLS
- Enforced atDatabase layer
- Sign-inEmail · Google · LinkedIn
- Team permissionsPer-organization roles
- Data exportCSV · JSON
Application hardening
Every request passes through middleware that sets a nonce-based Content Security Policy and the standard browser protections. Authentication and API endpoints are rate limited per client.
- Content Security PolicyPer-request nonce
- HSTSEnabled in production
- FramingX-Frame-Options: DENY
- Rate limitingAuth & API endpoints