# Vulnerability 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 how Touch2Sign identifies, prioritises, remediates, and tracks security vulnerabilities in application code, dependencies, and cloud infrastructure. Supports ISO 27001 A.8.8 and SOC 2 CC7.1.

## 2. Scope

Covers:

- Application source code (Next.js / Node.js)  
- Third-party npm dependencies  
- AWS infrastructure (App Runner, RDS, S3, IAM misconfigurations)  
- Container and runtime images where applicable  
- Findings from penetration tests and bug bounty (if launched)  

## 3. Vulnerability sources

| Source | Frequency | Owner |
|--------|-----------|-------|
| **GitHub Dependabot** | Continuous | Engineering |
| **npm audit** | Weekly in CI | Engineering |
| **AWS Inspector / Security Hub** | Continuous (when enabled) | Engineering |
| **Manual code review** | Per PR | Engineering |
| **Penetration test** | **Annual** minimum | Security Lead |
| **Customer / researcher reports** | Ad hoc | security@touch2sign.com |
| **CVE monitoring** | Continuous | Security Lead |

## 4. Severity classification

Align with CVSS v3.1 where applicable:

| Severity | CVSS range | Examples |
|----------|------------|----------|
| **Critical** | 9.0 – 10.0 | RCE in production, auth bypass, exposed DB, active exploitation |
| **High** | 7.0 – 8.9 | SQLi with constraints, privilege escalation, sensitive data leak path |
| **Medium** | 4.0 – 6.9 | XSS stored, CSRF on sensitive action, outdated lib with known exploit chain |
| **Low** | 0.1 – 3.9 | Information disclosure minimal impact, hardening opportunities |
| **Informational** | N/A | Best practice; no SLA |

Touch2Sign may escalate severity based on exploitability in our environment (e.g. signing token exposure = Critical).

## 5. Remediation SLAs

| Severity | Remediation target | Escalation if missed |
|----------|-------------------|----------------------|
| **Critical** | **7 calendar days** | CEO + daily IC standup |
| **High** | **30 calendar days** | Security Lead weekly review |
| **Medium** | **90 calendar days** | Sprint backlog |
| **Low** | Next maintenance window | No escalation |
| **Informational** | Best effort | — |

SLAs start from confirmed triage date, not original discovery date.

### 5.1 Emergency patching

For actively exploited Critical vulnerabilities:

1. Security Lead declares emergency change — see Change Management Policy  
2. Patch or mitigate within **24 hours** where possible (WAF rule, feature disable, hotfix)  
3. Full fix within 7-day Critical SLA  
4. Post-incident review if customer impact  

## 6. Vulnerability management process

### Phase 1 — Detection

- Dependabot alerts triaged within **2 business days**  
- Pentest findings logged in vulnerability register within **24 hours** of report receipt  

### Phase 2 — Triage

For each finding, record:

| Field | Description |
|-------|-------------|
| ID | VULN-YYYY-NNN |
| Source | Dependabot / pentest / etc. |
| Affected component | Package, service, endpoint |
| Severity | Critical / High / Medium / Low |
| Exploitability | Public exploit Y/N |
| Customer data at risk? | Y/N |
| Owner | Named engineer |
| Due date | Per SLA |
| Status | Open / In progress / Mitigated / Closed / Accepted |

### Phase 3 — Remediation

- Apply vendor patches or upgrade dependencies via PR with review  
- Infrastructure fixes via IaC or AWS console with change log  
- Verify fix in staging before production  
- Re-scan to confirm closure  

### Phase 4 — Exception handling

If SLA cannot be met:

- Document compensating controls (WAF, network isolation, feature flag off)  
- Risk acceptance signed by Security Lead; Critical/High also require CEO  
- Exception expiry date — maximum **90 days** for High; Critical exceptions require active mitigation  
- Entry in risk register  

## 7. Penetration testing

| Requirement | Detail |
|-------------|--------|
| Frequency | At least **annually**; after major architecture change |
| Scope | Production-like environment; signing flows; admin routes; API |
| Provider | Independent third party; NDA and rules of engagement |
| Retest | Critical/High findings retested after remediation |
| Report retention | **3 years** minimum |

First pentest target: **Month 9** of compliance programme.

## 8. Secure disclosure

External researchers may report vulnerabilities to **security@touch2sign.com**. Touch2Sign will:

- Acknowledge receipt within **3 business days**  
- Provide status updates in good faith  
- Not pursue legal action for good-faith research within published scope  
- Coordinate disclosure timeline with reporter  

## 9. Metrics and reporting

Reported to Security Lead monthly:

- Open vulnerabilities by severity and age  
- SLA compliance rate  
- Mean time to remediate (MTTR) by severity  
- Dependabot alert backlog  

## 10. Related documents

- Secure Development Policy  
- Change Management Policy  
- Incident Response Plan  
- Risk Management Policy  

## 11. Review

Reviewed **annually** and after significant vulnerability-related incidents.

---

**Approval**

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