Security

Security program

Security is a shared responsibility between EmailGuard, our customers, and our subprocessors. We design EmailGuard with safeguards for authentication, authorization, auditability, data protection, operational reliability, and responsible vulnerability handling.

This page is example security documentation for an enterprise SaaS deployment. Review and adapt it to match your actual production controls before sharing with customers.

Governance and ownership

We assign ownership for security-relevant engineering and operational work. Security responsibilities may include access reviews, incident response, dependency review, vulnerability triage, logging, monitoring, and customer security questionnaires.

Enterprise customers may request additional security documentation under NDA or a signed agreement by contacting [email protected].

Account security

The product includes security-focused account features such as:

• Password-based authentication with email verification and password reset flows.
• Optional Google and GitHub OAuth sign-in when enabled.
• Multi-factor authentication support.
• Team roles, invitations, and membership controls when team features are enabled.
• Account and team audit log surfaces for security-relevant activity.
• Session-aware API access controls and authenticated routes.

Customers are responsible for provisioning users, enforcing internal access policies, removing access when personnel leave, and protecting devices and credentials.

Application and API security

The application uses layered controls, including:

• Authentication and authorization middleware.
• Module-aware route guards.
• CORS controls and security headers.
• Request timeouts and structured error handling.
• Rate-limit-ready Redis infrastructure.
• Server-side validation patterns.
• Generated API clients and typed schemas where available.
• Segregated worker processes for background jobs.

Data protection

Production deployments should use encryption in transit for external traffic and managed or deployment-provided protections for databases, caches, object storage, backups, and logs. Access to production systems should be limited to authorized personnel with a business need.

Where supported by infrastructure, deployments should use:

• TLS for public endpoints.
• Encrypted storage volumes or managed database encryption.
• Secret management outside source control.
• Environment-specific credentials.
• Least-privilege service accounts.
• Backup retention and restoration testing.

Infrastructure and operations

The template supports Docker-based deployments, managed hosting, PostgreSQL, PgBouncer, Redis, background workers, and observability components. Production deployments should document their chosen providers, regions, backup schedules, retention windows, and operational owners.

Logging and monitoring

The codebase supports error reporting and observability through Sentry, OpenTelemetry, structured logging, metrics, and worker/API separation. Logs and telemetry should be reviewed according to severity and operational impact.

Sensitive values should not be intentionally logged. If sensitive data is found in logs, it should be handled according to incident response and retention procedures.

Vulnerability management

We review and address vulnerabilities based on severity, exploitability, exposure, and customer impact. Sources may include dependency scanners, CI checks, customer reports, internal reviews, and third-party advisories.

High-risk vulnerabilities should be prioritized for remediation or mitigation. Lower-risk findings may be scheduled based on impact and compensating controls.

Incident response

A security incident is an event that compromises or reasonably threatens the confidentiality, integrity, or availability of the service or customer data. Incident response should include:

1. Triage and severity assessment.
2. Containment and mitigation.
3. Investigation and evidence preservation.
4. Customer and regulatory notification when required.
5. Remediation and recovery.
6. Post-incident review and control improvements.

Customer notification obligations may be governed by a signed agreement or Data Processing Addendum.

Vulnerability disclosure

If you believe you found a security vulnerability, email [email protected]. Please include:

• A clear description of the issue.
• Steps to reproduce or proof-of-concept details.
• The affected URL, API endpoint, account, or mobile flow.
• Potential impact and suggested severity.
• Your contact information.

Please do not access, modify, delete, or exfiltrate data that does not belong to you. Give us a reasonable opportunity to investigate and fix the issue before public disclosure.

Out of scope

The following are generally out of scope unless they demonstrate a direct security impact:

• Reports from automated scanners without a working exploit path.
• Social engineering, phishing, or physical attacks.
• Denial-of-service testing without prior written approval.
• Missing headers or cookie flags that do not create a practical exploit in this application.
• Findings requiring compromised customer credentials or devices.

Contact

Security questions and vulnerability reports should be sent to [email protected].