Encryption & Key Management Policy

Version: 1.0 · Status: Active · Effective: 2026-05-05

1. Purpose

This policy describes the encryption standards, key management practices, and cryptographic controls that Projan AI Ltd (company number 17196385) applies to protect customer data and sensitive credentials across the Projan platform. It is intended for customers, partners, and auditors who need assurance that appropriate safeguards are in place.

2. Scope

This policy applies to:

Encryption of sensitive data at rest, including OAuth tokens, integration credentials, and API keys
Encryption of all data in transit between clients and Projan services
Key derivation, storage, and rotation practices
Cryptographic controls used in authentication and authorisation flows

All environments (development, testing, and production) operate under the same cryptographic standards. Production environments enforce the strictest access controls.

3. Encryption at Rest

Standard

All sensitive credentials stored within Projan are encrypted using AES-256-GCM, an authenticated encryption scheme that provides both confidentiality and integrity protection. This is the same cipher suite recommended by NIST (SP 800-38D) and widely adopted across the financial services and healthcare industries.

What We Encrypt

OAuth access tokens and refresh tokens for connected integrations (e.g. project management tools, messaging platforms, documentation services)
Integration credentials stored on behalf of users and teams
Any sensitive string that passes through our encryption pipeline

Integrity Guarantees

AES-256-GCM produces an authentication tag alongside the ciphertext. Any tampering with the encrypted data, including truncation or bit-flipping, is detected at decryption time and the operation is rejected. This prevents both accidental corruption and deliberate modification of stored secrets.

Input Validation

Our encryption routines enforce strict input validation. Null values, non-string types, and empty or whitespace-only inputs are rejected before any cryptographic operation is attempted.

4. Encryption in Transit

All traffic between clients and Projan services is encrypted using TLS (Transport Layer Security). Specifically:

HTTPS is enforced on all API endpoints, web application traffic, and marketing pages. Plaintext HTTP connections are automatically redirected to HTTPS.
WebSocket connections used for real-time features (e.g. live document updates, subscription notifications) are routed through the same TLS-terminated infrastructure.
Secure cookie attributes are applied where cookies are used, ensuring they are transmitted only over encrypted connections.
Internal service-to-service communication within our cloud infrastructure uses encrypted channels provided by the hosting platform.

5. Key Management

Key Derivation

Encryption keys are derived from master secrets using PBKDF2 (Password-Based Key Derivation Function 2), an industry-standard algorithm defined in RFC 8018. PBKDF2 applies a pseudorandom function iteratively to produce cryptographic keys that are resistant to brute-force and dictionary attacks.

The hash function, iteration count, and output key length are configured in line with current NIST and OWASP recommendations.
Derivation parameters are reviewed at least annually and increased as computational capabilities advance.

Key Rotation

Master secrets can be rotated without downtime through our managed secret store.
Rotation schedules are determined by risk assessment and compliance requirements.
Key rotation procedures are tested as part of our operational readiness reviews.

Separation of Environments

Each deployment environment (development, testing, production) maintains its own independent set of encryption keys and secrets. There is no sharing of key material across environment boundaries.

6. Secret Storage

Managed Cloud Secret Store

All secrets (database credentials, API keys, signing keys, encryption master keys) are stored in a managed cloud secret store with the following properties:

Encryption at rest: The secret store encrypts all values using its own envelope encryption with hardware-backed keys.
Access control: Secrets are accessible only to the specific service roles that require them, enforced through fine-grained identity and access management policies.
Audit logging: All secret access events are logged and available for security review.
Per-environment isolation: Each environment has its own secret namespace and access policies, preventing cross-environment secret leakage.

What We Never Do

We never store secrets in source code, configuration files, or environment variable definitions committed to version control.
We never expose secret values in infrastructure deployment outputs or logs.
We never transmit secrets in plaintext between services.

7. Cryptographic Controls

API Key Verification

API keys are verified using one-way cryptographic hashing. Only the hash of an API key is stored; the original key value cannot be recovered from storage. When a key is presented for authentication, its hash is computed and compared against the stored value.

Timing-Safe Comparison

Security-sensitive comparison operations (such as verifying OAuth state parameters and other security tokens) use constant-time comparison algorithms. This prevents timing side-channel attacks, where an attacker could infer secret values by measuring how long a comparison takes to complete.

Cryptographically Random Token Generation

All security tokens, including OAuth state parameters and session identifiers, are generated using a cryptographically secure random number generator (CSPRNG). This ensures tokens are unpredictable and resistant to guessing or enumeration attacks.

Token Expiry

Security tokens used in transient flows (such as OAuth authorisation) are assigned short time-to-live values, minimising the window of opportunity for replay or interception attacks.

8. Review Schedule

Activity	Frequency
Full policy review	Annually, or following a security incident
Key derivation parameter assessment	Annually
Secret rotation	Risk-based; at minimum following personnel changes or suspected compromise
Cryptographic dependency audit	Quarterly
Secret store access review	Quarterly

9. Contact

For questions about this policy, to report a security concern, or to request further detail on our cryptographic controls, contact us at:

Email: security@projan.ai

Projan AI Ltd (company number 17196385) is committed to transparency in our security practices. We welcome responsible disclosure and will respond to security enquiries within five business days.

Policies