Doctrine Encrypted Contracts Laravel Package

Product Decisions This Supports

• Compliance & Security Roadmap: Enables encrypted storage of sensitive data (e.g., PII, financial records, or health data) in Doctrine ORM without custom development, aligning with GDPR, HIPAA, or PCI-DSS requirements.
• Build vs. Buy: Avoids reinventing encrypted column abstractions for Doctrine, reducing technical debt and accelerating feature delivery.
• Multi-Tenant SaaS Use Cases: Securely isolates tenant data in shared databases by encrypting columns at the application layer.
• Legacy System Modernization: Safely encrypts sensitive fields in existing Doctrine-based applications without schema migrations.
• Third-Party Integration: Provides a foundation for building custom encrypted field types (e.g., for audit logs or masked reporting).

When to Consider This Package

• Adopt if:

  • Your PHP/Laravel app uses Doctrine ORM and requires column-level encryption (e.g., for sensitive fields like passwords, SSNs, or API keys).
  • You need reusable abstractions to extend doctrine-encrypted-bundle without low-level cryptography work.
  • Your team lacks cryptography expertise but needs FIPS-compliant or AES-256 encryption out of the box.
  • You’re building a modular security layer (e.g., for plugins or microservices) and want to standardize encryption patterns.

• Look elsewhere if:

  • You’re using Eloquent (Laravel’s default ORM)—this package is Doctrine-specific.
  • Your encryption needs are field-level only (consider Laravel’s built-in encrypt column type or tightenco/ziggy).
  • You require client-side encryption (e.g., for browser-based apps).
  • Your stack uses non-Doctrine databases (e.g., MongoDB, PostgreSQL with custom types).
  • You need key management as a service (KMaaS)—this package assumes manual key handling.

How to Pitch It (Stakeholders)

For Executives: "This package lets us encrypt sensitive data in our Doctrine databases without custom cryptography work, reducing compliance risk and development time. For example, we could securely store customer PII or payment details in shared environments—like a multi-tenant SaaS—while keeping costs low. It’s a drop-in abstraction for a proven encryption bundle, so we avoid reinventing the wheel. The MIT license and active maintenance (recent 2024 updates) make it a low-risk choice."

For Engineering: *"This gives us a clean way to add encrypted column types to Doctrine without writing boilerplate. It’s designed to work with aeliot/doctrine-encrypted-bundle, which handles the heavy lifting of AES-256 encryption. We’d use it to:

• Define custom encrypted fields (e.g., EncryptedString, EncryptedJson) in Doctrine entities.
• Reuse validation/logic for encrypted data (e.g., masking in logs).
• Integrate with existing security workflows (e.g., key rotation via Hashicorp Vault). The package is lightweight (no dependents = untested but simple), so we’d need to validate it against our encryption requirements—but it could save us weeks of dev work."*

For Security/Compliance: *"This provides a standardized way to encrypt data at rest in Doctrine, which helps with:

• GDPR/HIPAA compliance by limiting exposure of sensitive fields.
• Audit trails (encrypted data can still be logged/accessed via application logic).
• Key management flexibility (we’d pair it with our existing key vault). The package abstracts cryptography details, so we’d need to vet its implementation (e.g., cipher modes, key derivation) but avoid rolling our own solution."*