# 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](../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 |