Access Control Policy

Touch2Sign Ltd

Version: 1.0

Effective date: 11 July 2026

Owner: Robert — Security Lead

Approved by: Robert — CEO / Managing Director

Next review: 11 July 2027

---

1. Purpose

Define how Touch2Sign Ltd controls access to information systems, customer data, and administrative functions. This policy ensures that only authorised individuals receive the minimum access required to perform their role, in support of GDPR, ISO 27001, and SOC 2 requirements.

2. Scope

Applies to:

• All Touch2Sign employees, contractors, and third parties with access to production systems or customer data
• AWS infrastructure (eu-west-1, Ireland) — IAM, RDS, S3, Secrets Manager
• Application authentication (Amazon Cognito) and admin routes
• Signing tokens and recipient access to documents
• Source code repositories (GitHub organisation)

3. Access control principles

1. Least privilege — access granted to the minimum set of permissions required for the role
2. Need to know — customer document content accessible only where operationally necessary
3. Separation of duties — production deployment and privileged access require independent approval where feasible; solo operator: compensating controls in SOLO_TEAM_OPERATING_MODEL.md
4. Defence in depth — MFA, network controls, and audit logging layered on top of identity controls
5. Timely revocation — access removed on role change or termination without delay

4. Identity and account management

4.1 Joiner–mover–leaver (JML)

Event	Actions	Owner	Target
Joiner	Create Cognito / AWS IAM account with role template; MFA enrolled before production access	Engineering Lead	Day 1
Mover	Review and adjust permissions within 5 business days of role change	Security Lead	5 days
Leaver	Disable Cognito user; revoke AWS IAM keys; remove GitHub access; rotate shared secrets if exposed	Engineering Lead	Same day

All JML actions are logged in the access change register.

4.2 Amazon Cognito (application users)

• Customer organisation accounts provisioned via self-service signup or admin invitation
• Admin and internal Touch2Sign accounts use dedicated Cognito user pool(s) separate from customer tenants where practicable
• Password policy and MFA requirements defined in the Password & Authentication Standard
• Session timeout configured for admin routes; signing sessions follow product rules (30-minute Part 11 session where enabled)

4.3 AWS IAM

• No long-lived root account keys; root MFA enabled
• IAM users and roles follow least-privilege policy templates
• Production database access via bastion or approved tooling only — no direct public RDS endpoints
• Service accounts use IAM roles (App Runner, Lambda) — not static credentials

4.4 GitHub

• Organisation membership requires MFA
• Branch protection on main / production branches — PR review required
• External collaborators reviewed quarterly; removed when engagement ends

5. Multi-factor authentication (MFA)

MFA is mandatory for:

System	MFA method	Exceptions
AWS console and IAM users	TOTP or hardware key	None for production
GitHub organisation (admin/write)	TOTP or passkey	None
Touch2Sign admin / internal Cognito accounts	TOTP, SMS (where supported), or WebAuthn	None
Customer Cognito accounts	Recommended; enforced per org policy where product supports	Document in customer settings

MFA bypass is not permitted except via documented break-glass procedure (Section 8).

6. Signing tokens and recipient access

Signing links use time-limited, cryptographically random tokens stored in the recipients table.

Control	Requirement
Token generation	Cryptographically secure random; sufficient entropy
Expiry	Configured per document / org settings; expired tokens rejected
Single-use	Where product enforces one-time access for sensitive flows
Invalidation	On document void, completion, or suspected compromise — see Incident Response Plan §7.1
Scope	Token grants access only to the linked document and signing actions — not admin or other tenants

Support staff must not access signing URLs on behalf of customers unless explicitly authorised and logged.

7. Quarterly access reviews

The Security Lead conducts quarterly access reviews covering:

• AWS IAM users, roles, and privilege policies
• Cognito admin and internal user accounts
• GitHub org membership and repository access
• Database read access grants
• Secrets Manager secret ACLs
• Break-glass account status

Review field	Description
Account ID	Username / ARN
Role / purpose	Job function justification
Last login	From CloudTrail / Cognito logs
MFA enabled	Y/N
Still required?	Approver sign-off
Action	Retain / modify / revoke

Reviews are documented in the access review spreadsheet; anomalies remediated within 10 business days.

8. Privileged access and break-glass

8.1 Privileged access

Privileged access includes: AWS administrator, RDS superuser, production Secrets Manager write, Cognito admin API, and emergency production deploy rights.

• Granted only to named individuals with business justification
• Time-limited elevation preferred (just-in-time) where tooling supports it
• All privileged actions logged via CloudTrail and application audit logs

8.2 Break-glass procedure

For emergencies when normal MFA or access paths are unavailable (e.g. identity provider outage):

1. Incident Commander authorises break-glass use
2. Dedicated break-glass IAM role used — credentials stored in sealed envelope / Secrets Manager with dual control
3. All actions logged; session recorded where possible
4. Post-incident: rotate credentials, review CloudTrail, document in incident register within 24 hours
5. Break-glass access disabled until next authorised use

9. Access violations

Suspected unauthorised access, credential sharing, or privilege abuse must be reported immediately to security@touch2sign.com. Follow the Incident Response Plan for containment.

10. Related documents

• Information Security Policy
• Password & Authentication Standard
• Incident Response Plan
• Secure Development Policy

11. Review

This policy is reviewed annually or after a significant access-related incident.

---

Approval

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