Secure Development 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 secure software development practices for the Touch2Sign eSignature and eWitness platform. Ensures that code changes are reviewed, tested, and deployed without introducing avoidable security defects or exposing secrets.

2. Scope

Applies to all engineering staff and contractors who:

• Write, review, or deploy application code
• Modify infrastructure configuration
• Integrate third-party libraries or APIs
• Access production or staging environments

3. Secure development principles

1. Security by design — consider data classification and threat model in feature design
2. Least privilege in code — API routes enforce tenant isolation and role checks
3. Defence in depth — validate input at boundary; parameterised queries; output encoding
4. No secrets in source — credentials only in Secrets Manager or local gitignored files
5. Test before production — QA sign flow executed before every production release

4. Source code management

4.1 GitHub workflow

Control	Requirement
Branch protection	Enabled on main and production branches when GitHub org allows
Pull requests	Required for merges to main; feature branches may commit directly to dev
Peer review	Standard team: minimum 1 approving review from another engineer. Solo operator (current): self-review against .github/pull_request_template.md security triage + automated lint/build/QA — see SOLO_TEAM_OPERATING_MODEL.md
CI checks	Lint, build, and QA smoke must pass before production deploy
Signed commits	Recommended for production merges

4.2 Prohibited in repository

• .env files with real credentials (.env.local is gitignored)
• AWS access keys, Stripe secret keys, database passwords
• Customer production data dumps
• Private keys or TLS certificates

If secrets are accidentally committed: rotate immediately, purge from history if needed, follow Incident Response Plan.

5. Dependency management

• New npm packages require justification in PR description
• Prefer well-maintained packages with active security advisories
• Dependabot alerts triaged per Vulnerability Management Policy
• Lock file (package-lock.json) committed and reviewed on dependency changes
• No packages from untrusted registries without Security Lead approval

6. Security testing before production

Before every production deployment, the releasing engineer completes checks from docs/QA_SIGN_FLOW.md:

Area	Minimum verification
Authentication	Cognito login, MFA where applicable
Signing flow	Create document → send → sign → audit trail
Witness flow	eWitness capture if changed
Part 11 / PIN	PIN gate, lockout, intent-to-sign if changed
WebAuthn / mobile	Platform biometric on supported device if changed
Admin routes	Authorisation enforced
Regression	No console errors on critical paths

Results documented in release ticket or deploy checklist.

7. Production deployment

Production deployments are performed only via the approved scripts:

```bash

bash scripts/rebuild-dev.sh # development (:4001)

bash scripts/deploy-prod.sh # production (:4000)

```

Requirement	Detail
Authorisation	Engineering Lead or delegated release manager
Change ticket	Linked change record with rollback plan
QA evidence	QA_SIGN_FLOW.md checklist attached
Timing	Prefer business hours unless emergency
Rollback	Previous tagged release identified before deploy

Ad-hoc manual production changes (AWS console edits) require change log entry and are discouraged — prefer IaC or scripted changes.

8. Environment separation

Environment	Data	Access
Local	Synthetic / anonymised	Developer
Staging	Synthetic; no production DB copy without approval	Engineering team
Production	Live customer data	Restricted; MFA required

Production database must not be used for development or demo purposes.

9. API and application security

Engineering teams must:

• Use parameterised SQL — no string concatenation for queries
• Validate and sanitise all external input (signing tokens, webhooks, uploads)
• Enforce authentication and authorisation on every API route
• Log security-relevant events to audit_log without logging secrets or PINs
• Set secure HTTP headers (CSP, HSTS where applicable)
• Limit file upload types and sizes for document ingestion

10. Security issue reporting

Internal discovery:

• Report to Security Lead or security@touch2sign.com
• Do not disclose externally until remediated and coordinated

External reports handled per Vulnerability Management Policy secure disclosure process.

11. Training

Engineers complete secure coding awareness as part of Security Awareness Training. Role-specific topics: OWASP Top 10, tenant isolation, secrets handling.

12. Related documents

• Vulnerability Management Policy
• Change Management Policy
• Cryptography & Key Management Policy
• QA_SIGN_FLOW.md
• Access Control Policy

13. Review

Reviewed annually and after security-related production incidents.

---

Approval

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