Set Security Issue Fix Deadlines with a Simple SLA Matrix

TL;DR — The fastest way to avoid arguments during a security incident is to agree on a small severity matrix now: Critical, High, Medium, Low, each with a response time and a fix deadline. The single most useful action is to put those exact times in writing in your contract, statement of work, or shared runbook, and name who is allowed to approve exceptions. Reading time: ~5 min

Goal

When you finish, you will have a written security issue fix policy your team and agency both approved: a table of severity levels, exact response and remediation deadlines, who decides severity, and where exceptions are recorded.

Prerequisites

• Your contract, statement of work, master services agreement, or shared runbook draft
• Access to the document you use with the agency: Google Docs, Microsoft Word, Notion, Confluence, or your ticketing system
• The name and email of the customer approver for security decisions
• The name and email of the agency approver for security decisions
• Your support channel details: shared email, ticket portal, Slack/Teams channel, or pager contact
• Your business-hours definition, for example: "Monday-Friday, 09:00-17:00 Europe/London"
• Your production system list, or at least which systems are customer-facing and which hold sensitive data

Steps

Step 1: Create a one-page security fix policy document

Open the document your team already uses with the agency and add a new page titled exactly:

Security Issue Response and Remediation SLA

If you use a ticketing system instead of a document, create a ticket template with this exact title:

Security Issue Response and Remediation SLA - Approved Policy

You should see a blank page or template with that exact title saved in your shared workspace.

Step 2: Paste the severity matrix with exact deadlines

Paste this table into the document exactly as written:

| Severity | Definition | Initial response target | Workaround target | Full fix target |
|---|---|---:|---:|---:|
| Critical | Active attack, confirmed data exposure, remote code execution, admin account compromise, or production outage caused by a security issue | 1 hour, 24x7 | 24 hours | 72 hours |
| High | Serious weakness with a realistic path to sensitive data access, privilege escalation, or major fraud; no confirmed active attack | 4 business hours | 3 business days | 7 calendar days |
| Medium | Security weakness with limited impact or requiring unusual conditions; no evidence of exploitation | 1 business day | 10 business days | 30 calendar days |
| Low | Minor weakness, hardening issue, missing header, low-risk library issue with no known exploit path in your environment | 2 business days | Not required | Next planned release, no later than 90 calendar days |

You should see a four-row table with exact times for response, workaround, and full fix.

Step 3: Add the rules for who sets severity and how disagreements are handled

Paste this block directly under the table:

Severity is proposed by the agency and can be changed by the customer approver.
If the customer and agency disagree, the higher severity applies until both sides approve a lower severity in writing.
The timer starts when the issue is first reported in the agreed support channel.
A workaround counts only if it reduces the risk in production.
A full fix counts only when the code or configuration change is deployed to production.
If a third-party vendor blocks the full fix, the agency must provide a workaround and a written risk note before the full-fix deadline expires.

You should see six short policy lines under the table.

Step 4: Add your support channel and business-hours definition

Paste this template and replace the values in brackets with your real details:

Agreed support channel: [security@yourcompany.com] and [agency ticket portal URL]
Customer approver: [Full Name, email, phone]
Agency approver: [Full Name, email, phone]
Business hours: [Monday-Friday, 09:00-17:00 Europe/London]
Production systems in scope: [public website, customer portal, API, admin panel, production database]
Systems out of scope: [internal prototypes, sandbox, demo environments]

Example:

Agreed support channel: security@example.com and https://support.example-agency.com
Customer approver: Alex Morgan, alex@example.com, +44 20 5555 0101
Agency approver: Sam Lee, sam@agency.example, +44 20 5555 0202
Business hours: Monday-Friday, 09:00-17:00 Europe/London
Production systems in scope: public website, customer portal, API, admin panel, production database
Systems out of scope: internal prototypes, sandbox, demo environments

You should see named people, a real inbox or portal, and a clear scope list.

Step 5: Add the exception process so deadlines do not get silently missed

Paste this block exactly:

Exception process:
1. The agency opens a ticket titled "Security SLA Exception Request - [issue name]" before the deadline expires.
2. The ticket must include: current severity, reason the deadline will be missed, temporary controls in place, new target date, and business impact.
3. Only the customer approver named above can approve the exception.
4. Approval is valid only when written in the ticket or document comments.
5. If no approval is recorded before the deadline, the original deadline remains in force.

You should see a five-line exception process with one named approval path.

Step 6: Add one worked example so both sides classify issues the same way

Paste this example section:

Example classifications:
- Critical: attacker used a stolen admin session and viewed customer records in production.
- High: a broken access control bug lets one logged-in customer read another customer's invoice by changing an ID.
- Medium: a rate limit is missing on a password reset endpoint, but there is no evidence of abuse.
- Low: the site is missing a recommended HTTP security header, but no direct exploit path is known.

You should see four examples that match the four severities.

Step 7: Send for approval with exact approval text

Send the document link by email or in your shared ticket with this exact message:

Please reply with: "Approved for use as the Security Issue Response and Remediation SLA effective immediately." If you want changes, edit the document directly and tag both approvers.

If you use a ticket, put this exact comment in the ticket:

Approval requested. Please comment exactly: "Approved for use as the Security Issue Response and Remediation SLA effective immediately." 

You should receive a written approval reply or a document comment with the exact approval sentence.

Step 8: Link the policy from your delivery workflow

Add the approved document link to the place where security issues are tracked.

Use one of these exact labels, depending on your tool:

Security SLA: [paste approved document URL here]

Common places to add it:

• In your provider's dashboard for project documentation, if available
• In your ticketing system project description
• In your shared runbook or onboarding page
• In the statement of work under a section titled exactly:

Security Issue Response and Remediation SLA

You should see the approved link in the same place people open incidents and delivery notes.

Verify it works

Do these checks end to end:

1. Open the approved document and confirm it contains:

Critical - 1 hour response - 72 hours full fix
High - 4 business hours response - 7 calendar days full fix
Medium - 1 business day response - 30 calendar days full fix
Low - 2 business days response - next planned release, no later than 90 calendar days

1. Confirm there are two named approvers and one support channel.

2. Confirm the exception process says approval must be written before the deadline expires.

3. Create a test ticket with this exact title:

TEST - Security issue classification check

And this exact body:

Severity proposed: High
Reason: Logged-in user can access another user's invoice by changing an ID in the URL.
Requested action: Confirm severity and SLA clock start.

The process works if both sides can point to the same severity, the same deadline, and the same approval path without a meeting.

[Issue Reported] ---- 1. classify ----> [Severity Set]
       |                                  |
       v                                  v
[Support Channel] ---- 2. start timer --> [SLA Clock]
                                          |
                                          v
                                   [Fix or Exception]

Common pitfalls

Using only "best effort" language

Mistake: The document says "best effort" or "promptly" instead of exact times.

Symptom: During an incident, nobody can prove whether the agency is late.

Fix: Replace vague words with the exact table in Step 2.

Defining response time but not full-fix time

Mistake: You agree only on acknowledgment time.

Symptom: The agency replies quickly but the issue stays open for weeks.

Fix: Add both "Workaround target" and "Full fix target" columns from Step 2.

No named approver for exceptions

Mistake: The policy says exceptions are allowed but does not say who can approve them.

Symptom: Deadline extensions happen in chat and later get disputed.

Fix: Add the exact approver lines from Step 4 and the exception process from Step 5.

Business hours are not defined

Mistake: The policy says "4 business hours" but does not name the timezone or days.

Symptom: One side counts local holidays or a different timezone.

Fix: Add a literal line such as Business hours: Monday-Friday, 09:00-17:00 Europe/London.

Severity definitions are too technical or too vague

Mistake: The table uses only CVSS or only labels like "serious" without examples.

Symptom: The same bug gets classified differently by different people.

Fix: Keep the plain-language definitions in Step 2 and the examples in Step 6.

The policy is approved verbally, not in writing

Mistake: People say "looks good" on a call, but nothing is recorded.

Symptom: Later, one side claims the SLA was never agreed.

Fix: Use the exact approval text in Step 7 and keep it in email, comments, or a ticket history.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.