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