Security Policy

1. Purpose and Scope

This policy describes the security practices Modern Pixel applies to the platforms it builds, hosts, and supports, and to the client data those platforms hold. It applies to Modern Pixel's production client environments and to the Modern Pixel personnel and systems that operate them.

Client-specific commitments, including data ownership, permitted use, breach notification, and data return and deletion, are set out in each client's agreement. This policy describes the controls; the agreement describes the rights.

Modern Pixel builds to highly secure controls, designed to be appropriate for the sensitive personal and health information that client platforms may hold.

These controls apply to Modern Pixel's production client platforms and are applied proportionately to the sensitivity and scale of each platform's data. Not every control applies to every platform; where a platform holds personal, health, or financial data, the corresponding controls below apply.

2. Hosting and Infrastructure

• Isolated environments. Each client platform runs in its own isolated, access-controlled environment, and client data is kept logically separate from other clients' data and from Modern Pixel's internal systems. Where a platform's sensitivity or scale warrants it, it runs on its own dedicated server; smaller platforms may run on shared, hardened infrastructure with strict separation between environments.
• Firewall. Only web and administrative traffic is reachable from the internet. Databases are bound to the server and are not reachable from the public internet.
• Production hardening. Debug output is disabled in production so internal errors never leak system details.
• Dependency auditing. Application dependencies are automatically audited for known security advisories.

3. Encryption in Transit

• TLS everywhere. All traffic is secured with a valid, fully-chained certificate.
• Forced HTTPS. Plain HTTP requests are redirected to HTTPS.
• HSTS. Browsers are instructed to use HTTPS only for the domain, preventing downgrade attacks.
• Hardened cookies. Session cookies are flagged Secure, HttpOnly, and SameSite.

4. Encryption and Protection at Rest

• Field-level encryption of the most sensitive credentials, including multi-factor secrets, recovery codes, and phone numbers.
• Password hashing. Passwords are hashed with a modern algorithm and are never stored in readable form.
• Encrypted backups. Automated database backups (at least daily for production) are written to private cloud storage with AES-256 encryption on each backup archive.
• Private file storage. Uploaded files are stored in private storage and served only through short-lived, signed links.

5. Authentication

• Invite-only accounts. There is no public sign-up for staff accounts. Users are provisioned by an administrator through a single-use, expiring invitation and set their own password; temporary passwords are never emailed.
• Strong password policy, aligned to NIST 800-63B: a 12-character minimum, checked against known-breached-password databases, without counterproductive forced rotation.
• Multi-factor authentication (2FA). Available to all users and required for any role that can reach sensitive data. Supported methods include an authenticator app (TOTP) and a one-time code by text message, backed by single-use recovery codes.
• Brute-force protection. Repeated failed sign-ins are throttled per account and per source and then temporarily locked out. Lockouts are recorded.
• Bot protection. A CAPTCHA challenge guards the sign-in form against automated and credential-stuffing attacks.
• Email verification and change protection. New accounts verify their email, and changing an email requires confirming a signed link sent to the new address, so an account's email cannot be silently hijacked.
• No account enumeration. Sign-in and password-reset responses are neutral so an attacker cannot probe which accounts exist.
• Session controls. Sessions expire after a period of inactivity and when the browser closes, session data is encrypted, and the session identifier is regenerated on every sign-in and identity change.

6. Authorization and Access Control

• Default-deny. Every feature ships locked. Access is granted explicitly, never by accident.
• Sensitivity tagging. Each module is tagged for the kind of data it exposes (personal, health, or financial). Sensitive areas are automatically restricted for non-administrators, marked in the interface, and audit-logged when viewed.
• Role presets with per-person overrides. Roles seed sensible defaults, and an administrator can fine-tune any individual user's access.
• Tiered access to sensitive information. Sensitive information is separated by need-to-know, so that different roles see the full record, a limited subset, completeness status only, or nothing, according to the client's configuration.
• Separation of audiences. Where a platform serves both staff and external end-user accounts (the client's own users, such as its members, participants, or customers), the two are walled apart, and an external account can reach only its own records.
• Lockout safeguards. The system prevents removing the last administrator or an administrator locking themselves out.
• Read-only impersonation. An administrator may preview the application as another user to verify access, in a strictly read-only mode that cannot change data. It requires the administrator's own 2FA, and the start and end of each session are recorded in the audit log.
• Least privilege for Modern Pixel personnel. Modern Pixel staff access client production data only as needed to provide and support the service.

7. Audit Logging and Monitoring

• Append-only audit log. Every view of sensitive data and every authentication event (sign-in, failed attempt, lockout, sign-out) is recorded with the user, IP address, device, and timestamp. Records cannot be edited after the fact.
• Administrator oversight reporting. The audit trail is surfaced to client administrators for oversight.
• Monitoring and alerting. Production environments are monitored, with alerting to Modern Pixel staff.
• Error monitoring is integrated for rapid detection of production issues.

8. Application Security

• CSRF protection on every state-changing action.
• Content Security Policy plus a full set of security headers (anti-clickjacking, MIME-sniffing protection, referrer and permissions policies).
• SQL-injection safe by construction through parameterized database access.
• Mass-assignment protection with explicit field allowlists; sensitive fields are set only in trusted server code.
• Rate limiting on registration, password-reset, and other sensitive endpoints.

9. Operational and Supply-Chain Security

• Tested-before-deploy gate. An automated test suite must pass before any change can be deployed; untested code cannot reach production.
• Secrets management. Application secrets live in an encrypted vault and the server's protected environment, never in source code.
• Cloud-account 2FA. Every infrastructure account that controls a client platform (hosting, source control, storage, telephony, payments) is protected with two-factor authentication.
• Change management. Changes are reviewed and deployed through a controlled pipeline.

10. Backups and Recovery

Automated daily backups are encrypted and stored separately from the production server. Modern Pixel monitors backup success and can restore a client environment from backup.

11. Sub-processors

Modern Pixel uses reputable third-party providers to deliver its services, in categories including hosting and infrastructure, backup and object storage, error monitoring, messaging and telephony, and payment processing. Payment card data is handled by a PCI-compliant payment processor; Modern Pixel does not store raw payment card numbers. Modern Pixel engages only providers that are subject to written confidentiality and data-protection terms appropriate to the data they handle, does not authorize any provider to use client data for its own purposes, and remains responsible for its sub-processors' performance as if Modern Pixel performed the services itself. Modern Pixel identifies its material sub-processors to a client on request.

12. Incident Response

Modern Pixel maintains a process to investigate, contain, mitigate, and remediate security incidents. If Modern Pixel becomes aware of a security breach that compromises a client's data, it notifies that client in accordance with the client's agreement and provides the information reasonably available about the incident.

13. Data Retention and Deletion

Client data is retained for as long as the client's agreement is in effect. Clients may request a complete export of their data at any time. Following termination, client data is deleted on the client's written request within the period stated in the client's agreement, except for copies held in routine encrypted backups, which are removed on the normal backup rotation, or where retention is required by law.

14. Changes to This Policy

Modern Pixel may update this policy to reflect improvements and evolving practice. Where a client agreement commits Modern Pixel to security measures "no less protective than" this policy, Modern Pixel will not make changes that materially reduce the protections described here.

15. Contact

Security questions, or to report a suspected vulnerability or incident:

Modern Pixel Marketing & Website Design
Email: support@modern-pixel.com