Security & Data Privacy

This page describes the security features built into Knowledge ERP. For specific compliance or data-processing questions, get in touch — see the bottom of the page.

Tenant data isolation #

Knowledge ERP is multi-tenant: your account's data is scoped to your account at the data layer. Every business record is tied to its owning account and queries are automatically constrained to it, so one customer can never see or touch another's records. This isolation is enforced centrally rather than left to individual screens.

Authentication #

People sign in through the appropriate door for who they are:

• Team members sign in to the app with their account credentials.
• Customers use the portal via a passwordless magic link — no customer password to manage or leak.
• Integrations authenticate to the API with bearer tokens (see below).

Role-based access control #

Access follows least privilege. Users are granted roles — named bundles of granular, per-resource permissions — and roles can be scoped to specific locations, so people only get the access their job needs. The same permissions gate the reports and dashboards: a report is open only to someone cleared for every kind of data it displays, so an aggregate cannot be a way around the records behind it. See Users, Roles & Permissions.

Infrastructure & hosting #

Knowledge ERP runs on AWS, with security built into the platform:

• Encrypted in transit — all traffic is served over HTTPS/TLS; plain HTTP is redirected to HTTPS and only modern TLS (1.2+) is accepted.
• Web application firewall — a WAF screens incoming traffic with managed rule sets (common exploits, known-bad inputs, SQL injection) plus per-IP rate limiting.
• Network isolation — application servers and the cache run in private networks with no direct internet access; only the load balancer is internet-facing, and internal tiers accept traffic only from the tier above.
• Encrypted at rest — server volumes, the cache, and object storage are encrypted at rest, and the cache is encrypted in transit too.
• Managed secrets — credentials and configuration live in a managed secrets store (never in code or images), retrieved with least-privilege access; the application picks up rotated database credentials automatically.
• Private asset delivery — public files are served through a CDN (CloudFront); the underlying storage bucket itself stays private.
• Auditing & monitoring — load-balancer access logs, network flow logs, and WAF metrics provide an infrastructure-level audit trail, with alerting on anomalies.
• Resilience — the app runs across multiple availability zones behind an auto-scaling load balancer, with zero-downtime (blue/green) deployments.

API & webhook safeguards #

• Tokens act as a person — every API token belongs to a user or a service account and can never do more than they can, so revoking someone's permissions (or removing them entirely) narrows every key they hold at once.
• Scoped tokens — API tokens can additionally be limited to specific modules with read-only or read/write access, so an integration only reaches what it should. A token's scope can be narrowed later without reissuing it.
• Service accounts — a token-owning identity that cannot sign in anywhere, so a long-lived integration neither depends on an employee's account nor gives anyone a way in. Capped per plan tier and consuming no seat.
• Module gating — every request is checked against your subscription, the token's scope, and the owner's own permissions. The API and the admin panel answer from the same policies, so there is no second set of rules to keep in step.
• No cross-module side doors — a limited token is also refused the endpoints that span every module (webhooks, automation, reports, the user directory) and the mobile endpoints, because no per-module grant can describe them. Those need a full-access token. See what a limited token can and cannot do.
• Rate limiting — requests are capped per plan to protect availability.
• Signed webhooks — outgoing webhooks are signed with an HMAC-SHA256 signature so your systems can verify they genuinely came from Knowledge ERP.

See API: Getting Started and Webhooks.

Payments #

Knowledge ERP records how a payment was received (cash, check, credit card, bank transfer, etc.) but does not collect or store raw card numbers. Card processing is handled outside the ERP by your own payment processor. The platform's own subscription billing is processed by Stripe; no raw billing card data is stored in your ERP data.

Audit trail #

Meaningful changes are recorded with who made them and when, across the app and the API, and most actions can be undone. This gives you accountability and a way to investigate or reverse changes. See Change History & Undo.

Your data #

• Recoverable deletes — major records are soft-deleted, so an accidental deletion can be recovered rather than lost outright.
• Your data is yours — you can export it at any time through the REST API.

Questions about security or compliance? #

Have specific requirements — data processing, residency, or compliance questions? We're happy to discuss them. Reach out to your Knowledge ERP contact and we'll work through your needs.