Cryptography & Key Management Policy

Touch2Sign Ltd

Version: 1.0

Effective date: 11 July 2026

Owner: Robert — Engineering Lead

Approved by: Robert — CEO / Managing Director

Next review: 11 July 2027

---

1. Purpose

Define cryptographic standards and key management practices for protecting Touch2Sign data in transit and at rest. Ensures consistent use of approved algorithms and secure handling of secrets across AWS eu-west-1 (Ireland).

2. Scope

Applies to:

• All production and staging environments on AWS
• Application-layer encryption and hashing
• TLS certificates and CDN configuration
• Database, object storage, and backup encryption
• Secrets, API keys, and signing credentials

3. Cryptographic standards

3.1 Approved algorithms

Use case	Approved	Prohibited
Data at rest	AES-256 (AWS KMS, S3 SSE, RDS encryption)	DES, 3DES, RC4
Data in transit	TLS 1.2+ (TLS 1.3 preferred)	SSLv3, TLS 1.0, TLS 1.1
Password hashing	bcrypt, Argon2, or Cognito-managed	MD5, SHA1 for passwords
Document integrity	SHA-256 or stronger	MD5 for audit evidence
Signing tokens	Cryptographically secure random (CSPRNG)	Predictable sequences

3.2 TLS configuration

• All customer-facing endpoints terminate TLS with valid public certificates
• CloudFront and App Runner configured for modern cipher suites
• HSTS enabled on production domains where supported
• Internal AWS service calls use HTTPS endpoints

4. Data at rest encryption

Asset	Encryption method	Key management
Amazon S3 (documents, assets)	SSE-S3 or SSE-KMS (AES-256)	AWS-managed or CMK in eu-west-1
Amazon RDS (PostgreSQL)	Encryption at rest enabled	AWS KMS
RDS backups / snapshots	Inherited from source	AWS KMS
EBS volumes	Encrypted	AWS KMS
Secrets Manager	Encrypted at rest	AWS KMS

Customer documents and audit data must not be stored on unencrypted volumes or buckets.

5. Key management

5.1 AWS KMS

• Customer master keys (CMKs) used for sensitive workloads where required
• Key policies follow least privilege — only authorised IAM roles may encrypt/decrypt
• Key rotation enabled for CMKs where AWS supports automatic rotation
• Key deletion requires 30-day waiting period and Security Lead approval

5.2 Secrets Manager

All production secrets are stored in AWS Secrets Manager:

• Database credentials
• Third-party API keys (Stripe, OneID, eID Easy, Anthropic, etc.)
• Webhook signing secrets
• Internal service tokens

Requirement	Detail
No secrets in git	.env.local gitignored; pre-commit checks where configured
Access	IAM role-based; no secrets in environment variables in source
Rotation	Database credentials rotated on schedule or after compromise
Audit	CloudTrail logs all GetSecretValue calls

5.3 Development and staging

• Staging uses separate secrets namespace — never production credentials
• Developers use local .env.local files — never committed to repository
• Synthetic data in non-production; production data dumps prohibited without encryption and approval

6. Application-level cryptography

• Document hashes stored for integrity verification in audit trails and signed PDFs
• Signing tokens generated with crypto.randomBytes or equivalent CSPRNG
• JWTs (where used) signed with strong algorithms (RS256, ES256) — secrets in Secrets Manager
• Passwords never stored in plaintext — delegated to Cognito

7. Key lifecycle

Phase	Actions
Generation	Use AWS or platform CSPRNG; document purpose and owner
Distribution	Via Secrets Manager or IAM role — never email or Slack
Use	Least-privilege access; log privileged retrieval
Rotation	Scheduled rotation or immediate on compromise — see Incident Response Plan
Revocation	Disable old key version; verify no dependent services fail
Destruction	KMS key deletion schedule; confirm backups re-encrypted if needed

8. Compromise response

On suspected key or secret compromise:

1. Rotate affected secret immediately in Secrets Manager
2. Revoke old IAM credentials / API keys
3. Review CloudTrail and access logs for unauthorised use
4. Follow Incident Response Plan if customer data may be affected
5. Document rotation in change log

9. Prohibited practices

• Committing keys, passwords, or certificates to Git
• Sharing secrets via unencrypted email or chat
• Using production keys in development or personal environments
• Disabling encryption on S3 buckets or RDS instances
• Custom cryptography without Security Lead and Engineering Lead approval

10. Related documents

• Information Security Policy
• Access Control Policy
• Incident Response Plan
• Secure Development Policy

11. Review

Reviewed annually and after major infrastructure or cryptography-related incidents.

---

Approval

Name	Role	Signature	Date
Robert	CEO / Engineering Lead	Electronic	11 July 2026