Trust is part of the system

Security requirements are part of every feature from the start: validation, authorization and safe error handling are built in, not added later.

Sign-in uses a mature, well-maintained authentication library. Passwords are hashed with a strong, salted algorithm and are never stored or logged in readable form. Email verification is required.

Optional authenticator-app (TOTP) two-factor authentication with one-time recovery codes. Required for PVology internal administrators.

Sessions use secure, HTTP-only cookies with same-site protection, expire automatically, and can be signed out on all devices.

Customer organizations have owner, administrator and member roles. PVology staff have separate, narrowly scoped internal roles. Nobody receives more access than their role needs.

Every organization-scoped request is checked on the server against the user's membership. Changing an ID in a link or form does not grant access to another organization.

Rate limits protect sign-in, registration, password reset, contact forms and Ask PVology. Automated form submissions are filtered.

Important security and administrative actions are recorded in an audit log. IP addresses are stored only as one-way hashes.

A strict Content Security Policy, clickjacking protection, secure headers and encrypted connections (HTTPS) in production.

We collect only what a feature needs. Analytics are first-party and do not use third-party tracking scripts.

AI assistance never bypasses permissions, never guarantees outcomes, never invents savings, and keeps people responsible for decisions. Only the minimum necessary text is sent for AI processing, and AI is off unless configured.

Owners and administrators decide client view links and their longest life, customer portal invitations, who may export data, whether automations may run and which integrations are allowed. These rules are enforced on the server and every change is recorded.

Every data export checks your organization's policy and is recorded. A refused export explains which rule applies and who can change it.

Failed sign-ins, sign-ins from a new device, role and policy changes, API keys, rotated webhook secrets and sensitive exports are listed for owners and administrators, with alerts for unusual activity such as repeated failed sign-ins.

PVology Connect encrypts connection credentials and shows them once; API keys, client secrets and tokens are stored only as fingerprints. API clients get only the scopes you choose, webhooks are signed, outgoing addresses are checked so PVology never calls internal networks, and logs never contain secrets.

Data is encrypted in transit with HTTPS. Two-factor secrets are encrypted at rest. Database storage encryption depends on the hosting environment and will be confirmed before launch.

Database backup and recovery procedures are documented and will be verified as part of production launch.

Single sign-on (OpenID Connect), verified domains and SCIM 2.0 provisioning are built and tested in PVology Connect and switched on per organization after a joint test with its identity provider. Owners always keep password sign-in.

An incident response process will be established before handling customer production data at scale.