Security Measures

This page describes the technical and organisational measures (TOMs) that PPS — Practical Programming Systems applies to protect personal data in PPS ERP, as required by Article 32 GDPR. It forms Annex 2 of our Data Processing Agreement. We review these measures regularly and adapt them to new risks; we will not reduce the overall level of protection.

• The platform is hosted in the European Union (EU/EEA) with a professional cloud provider; physical data-centre security is provided by that provider and its certified facilities.
• Traffic passes through a network provider with DDoS mitigation and bot protection.
• Production and development environments are separate, with separate databases and credentials.

• Every customer workspace has its own, separate database schema.
• The workspace a request may access is taken from a cryptographically signed access token — never from a value the browser can change — and is checked again independently before data is read.
• Uploaded files are stored under a separate path per workspace and are only reachable through short-lived signed links.

• All connections use TLS (HTTPS); HTTP Strict Transport Security is enforced.
• Credentials for connected integrations (marketplaces, payment and email providers) are encrypted at application level before they are stored and are never returned by the API.
• Passwords are stored only as salted Argon2 hashes.

• Role-based access control with per-module permissions and, for stores and warehouses, per-location permissions.
• Sensitive personal fields such as national identification numbers and bank account numbers are masked unless a user holds an explicit permission.
• Administrators manage users and roles; deactivated users lose access immediately.
• PPS platform staff use a separate administration system with its own identities; every action is recorded.

• Two-factor authentication with an authenticator app (with single-use recovery codes) is available for every user and for PPS platform staff.
• Email verification is required before first sign-in.
• Accounts are temporarily locked after repeated failed sign-in attempts, and sign-in, sign-up and verification endpoints are rate-limited.
• Short-lived access tokens (30 minutes) with rotating refresh tokens; revoked tokens cannot be reused.
• Sessions end automatically after a period of inactivity.
• Bot protection on the public sign-up form.

• Support staff can enter a workspace only if the customer has enabled support access.
• Each session needs a documented reason, uses a one-time token, is limited to 15 minutes, cannot be extended and is visible to users as a banner.
• Every support session is written to the customer's audit trail.

• Security-relevant actions — sign-ins, failed sign-ins, user and role changes, HR and payroll changes, exports, support sessions — are recorded in an audit trail available to customer administrators.
• Values of sensitive fields (identification numbers, bank details, salaries) are masked in audit records.
• Audit trails and the consent ledger are append-only at database level: they cannot be edited or deleted by application code, only aged out by the retention process.
• Personal data of buyers and secrets are removed from technical logs of marketplace integrations before they are stored.
• Retention periods are enforced automatically; technical logs are deleted after short, fixed periods.

• Managed database backups with a rolling retention period.
• Background work runs in queues with retries, so temporary failures do not lose data.
• Customers can export their data at any time.

• Changes are reviewed and tested before release; automated tests cover critical workflows such as stock, sales, billing and tenant isolation.
• Database changes are applied through versioned migrations.
• Third-party dependencies are kept up to date and monitored for known vulnerabilities.

• Access to production systems is limited to the people who need it and is protected with strong authentication.
• Everyone with access to personal data is bound by confidentiality.
• Sub-processors are selected with care and bound by data processing agreements (see our sub-processor page).

We maintain an incident response procedure. We notify affected customers of a personal data breach without undue delay and at the latest within 48 hours after becoming aware of it, and where we are controller we notify the supervisory authority within 72 hours as required by Article 33 GDPR.

Please report security issues to info@ppserp.com. We investigate every report and do not take action against good-faith research that respects customer data and service availability.