Templates · 7 min read

The security incident log template, with a severity scale and review record

One row per security event, opened at triage and never deleted. It is the record an auditor reads against CC7.3, CC7.4 and CC7.5, even in a quiet year.

A security incident log template gives you one row per security event or incident: when it was detected, how severe it was, whether customer data was affected, what contained it, what caused it, whether customers were told, and when it was reviewed. For SOC 2 it is the record behind CC7.3, CC7.4 and CC7.5.¹

The workbook has the log, a four level severity scale, a post-incident review sheet and a short guide. It comes filled in with three rows from Moonrake, a fictional ten person company on AWS.

Why an auditor asks for the log, even when it is empty

Incident handling sits in the common criteria, so it is in scope on every SOC 2 report. Three criteria carry it. CC7.3 is triage: deciding whether an event is a security incident. CC7.4 is the response: contain it, fix it and tell the people who need to know. CC7.5 is recovery: restore what broke and close the actions the review found.¹

A log with no incidents in it still answers the first of those. The rows closed at the lowest level show that alerts and reports were looked at and a decision was made. A quiet period ends with a short statement, signed by management, that no security incidents were identified. That statement is evidence too. The auditor reads it beside the alert history and the tickets, so it has to match them. Expect the log near the top of the auditor’s request list either way.

Security incident log template, full text

The columns run in the order an incident does: detected, contained, eradicated, recovered, reviewed. National Institute of Standards and Technology (NIST) Special Publication 800-61 Revision 3 frames the same work through the Detect, Respond and Recover functions of its Cybersecurity Framework 2.0, with the lessons from each incident feeding improvement.² The four severity levels are the three tiers of the incident response plan template plus its row for events that are not incidents, so the plan and the log never disagree.

[Company name]

Security Incident Log

Owner: [Security owner role]
Kept in: [Ticketing system]
Covers: Every security event triaged and every security incident
Version: [Version]

1. How to use this log

This log is the one list of every security event [Company name] triaged and every security incident it handled. The Incident Response Plan says how an incident is run. This log is the record that it was. Keep one row per event, in the workbook or in [Ticketing system], and keep the same columns either way.

Open a row the moment an event is triaged, not when it is resolved. Fill in what is known, write Unknown where nothing is known yet, and update the row as the response moves. A row is never deleted. An event that turns out not to be an incident stays in the log at SEV4, because the row is the evidence that it was looked at.

Criterion	What it expects	What the log shows
CC7.3	Security events are evaluated to decide whether they are security incidents	Each event triaged and given a severity, including the ones closed as SEV4
CC7.4	Identified incidents are handled under a defined response: understood, contained, remediated and communicated	Containment, eradication, recovery and the customer notification decision for each incident
CC7.5	Activities to recover from identified incidents	Recovery, root cause and the post-incident review with its actions closed

2. The severity scale

Set the level at triage and raise it if the facts change. Each level has a trigger anyone on call can apply and a clock.

Level	Name	Trigger	Who is told	Clock
SEV1	Critical	Customer data reached by someone who should not have it, or production down for all customers	Incident lead by phone at once, then the executive who sends customer notices	Contained the same day. The customer notice clock starts when the incident is declared
SEV2	High	A control failed and could have exposed data, or production degraded for some customers	Incident lead within the hour	Contained the same day. Reviewed within five business days
SEV3	Moderate	One account, device or dependency affected, and no data was reached	A ticket, picked up the next business day	Closed inside the remediation window your policy states
SEV4	Event	A security event triaged and found not to be an incident: a scanner finding with no sign of use, failed sign ins, a phishing email nobody clicked	Nobody is woken. The row is the record of the triage	Closed at triage, or moved to the vulnerability queue

These four levels are the three tiers of the Incident Response Plan template plus its "not an incident" row. If your plan uses different levels, copy them here so the plan and the log never disagree.

3. What each column holds

Column	What to enter
Incident ID	A number that never repeats, for example INC-104. The same ID goes on the ticket, the review and any customer notice.
Detected on	The day the event was first seen, from the alert or the report, not the day someone opened the ticket.
Reported by	The person, customer, vendor or tool that raised it.
Detection source	Monitoring alert, staff report, customer report, vendor notice, third party report, or audit or review.
Severity	SEV1 to SEV4 from the severity scale. If the level changed during the response, write the final level and note the change in the summary.
Category	Unauthorized access attempt, unauthorized access, credential exposure, malware, phishing, data exposure, denial of service, lost or stolen device, vendor incident, misconfiguration, or other.
Systems affected	The systems named in your system inventory, not a general description.
Customer data affected	Yes, No or Unknown. Unknown is an honest answer while the facts are coming in. Change it once they are established, and say how.
Summary	Two or three sentences a reader outside the response can follow.
Containment action	What stopped the harm from spreading.
Contained at	When containment finished, counted from detection, for example same day, 35 minutes after the report.
Eradication	What removed the cause.
Recovery	What brought the affected systems back to normal operation.
Restored at	When normal operation resumed, counted from detection.
Root cause	The cause the review settled on, including any cause at a vendor.
Customer notification required	Yes, No or Under review, judged against your contracts, your published commitments and any law that applies.
Notification sent	The day the notice went out and who sent it, or Not required.
Post-incident review date	The day the written review was held. Every SEV1 to SEV3 incident gets one.
Owner	The role accountable for closing the row.
Status	Open, Contained, Resolved or Closed. Closed means every review action is done.

4. Worked example

Three rows from the log of Moonrake, a fictional ten person company that sells API security monitoring to fintech companies and runs on AWS. The full rows, with every column and two post-incident reviews, are in the workbook.

ID	Detected	Level	Category	Customer data	What happened and what was done	Notification	Status
INC-104	11 February	SEV3	Unauthorized access attempt	No	Okta push requests the engineer had not started, all denied. Sessions revoked, password reset, number challenge turned on.	Not required	Closed
INC-107	7 April	SEV2	Credential exposure	No	An AWS pipeline key in a pull request. Deactivated in 25 minutes, CloudTrail showed no other use, pipeline moved to short lived credentials.	Not required	Closed
INC-112	12 August	SEV1	Vendor incident	Yes	The help desk vendor was breached and four tickets with customer contact details and one pasted API token were read. Token and integration key revoked.	Sent 14 August to the four customers	Closed

5. The post-incident review record

Every SEV1 to SEV3 incident gets a short written review within five business days. Record it on the Post-incident review sheet, or in the ticket, with:

The incident ID, the review date and who attended.
A timeline with times: detected, declared, contained, restored and, where it applies, customers notified.
How long it took to detect and to contain.
What worked and what did not.
The root cause.
At least one action, with an owner, a due date and the date it closed.

6. When there were no incidents

A period with no incidents still leaves a record. The log shows the events triaged and closed at SEV4, and management signs the statement below at the end of the period. Auditors read it beside the alert history and the tickets, so sign it only when the log supports it.

6.1 Statement of no security incidents

The management of [Company name] states that no security incidents, as the Incident Response Plan defines them, were identified during the period [Period start] to [Period end]. Every security event triaged during the period is recorded in the security incident log, at SEV4, with the triage decision.

[Signer name], [Signer title], [Company name]

Sign-off. Name, signature and date for: Officer signing for management.

7. Keeping the records

Keep the log, the tickets behind each row, the reviews and any customer notices for the period the Data Retention Policy sets for security records.
Store them in [Evidence storage location], where an auditor can be given them, and restrict editing to the [Security owner role].
Never edit a closed row to change what happened. Add a note with the date and the correction.

8. Fields to complete

Replace every bracketed field in this document with your own detail, then delete this section.

Field	What to enter
[Company name]	Your legal company name.
[Version]	Start at 1.0 and increase it each time the document changes.
[Security owner role]	The role that runs the security program day to day, for example Chief Technology Officer.
[Evidence storage location]	The shared folder or system where evidence is kept.
[Ticketing system]	Where changes and incidents are tracked, for example Jira or Linear.
[Period start]	For a Type 2 report, the first day of the period.
[Period end]	For a Type 2 report, the last day of the period.
[Signer name]	The officer signing for management.
[Signer title]	Their title, printed under the name.

The workbook

Three rows from Moonrake: an Okta push attack on one engineer, an AWS key caught in a pull request, and a breach at its help desk vendor that reached four support tickets. Only the last touched customer data, and it is the only one with a customer notice. The review sheet carries the written reviews of the two most serious, with their actions closed.

Security Incident Log

Incident log

One row per security event or incident, opened at triage and never deleted. The three rows are an example from Moonrake, a fictional ten person company on AWS: replace them with your own.

Incident ID	Detected on	Reported by	Detection source	Severity	Category	Systems affected	Customer data affected	Summary	Containment action	Contained at	Eradication	Recovery	Restored at	Root cause	Customer notification required	Notification sent	Post-incident review date	Owner	Status
INC-104	2026-02-11	Senior engineer	Staff report	SEV3	Unauthorized access attempt	Okta staff sign in	No	An engineer received 14 Okta push requests at night that he had not started. He denied all of them and reported it in the security channel.	Okta sessions revoked and the password reset for the account	Same day, 35 minutes after the report	Okta number challenge turned on for every staff push sign in	The engineer signed back in with the new password	Same day	The password had been reused on a third party site that was breached	No	Not required	2026-02-17	Chief technology officer	Closed
INC-107	2026-04-07	GitHub secret scanning	Monitoring alert	SEV2	Credential exposure	AWS production account, GitHub	No	Secret scanning flagged an AWS access key in a pull request on a private repository. The key belonged to the deployment pipeline and could write to production.	Key deactivated in AWS Identity and Access Management	Same day, 25 minutes after the alert	Key deleted, the commit removed from the branch history, and AWS CloudTrail searched for any use of the key outside the pipeline: none found	Pipeline moved to short lived credentials through GitHub OpenID Connect	Same day, 3 hours after the alert	A long lived key copied into a local test file that was committed by mistake	No	Not required	2026-04-10	Engineering lead	Closed
INC-112	2026-08-12	Help desk vendor security team	Vendor notice	SEV1	Vendor incident	Customer support help desk (vendor service)	Yes	The help desk vendor reported that an attacker used a stolen vendor support credential to read customer tickets over two days. Four Moonrake tickets were read. They held customer contact names and email addresses, and one held a Moonrake API token a customer had pasted.	The pasted API token and the help desk integration key revoked, and the integration paused	Same day, 2 hours after the notice	The vendor reset its support credentials and confirmed in writing that the access path was closed	New integration key issued after the written confirmation, and the integration resumed	Two days after detection	At the vendor, a support credential without multi-factor authentication. At Moonrake, the help desk kept API tokens that customers pasted into tickets	Yes	2026-08-14, by the chief executive officer to the four customers	2026-08-18	Chief technology officer	Closed

Severity scale

Set the level at triage and raise it if the facts change. Keep these levels identical to the ones in the incident response plan.

Level	Name	Trigger	Who is told	Clock
SEV1	Critical	Customer data reached by someone who should not have it, or production down for all customers	Incident lead by phone at once, then the executive who sends customer notices	Contained the same day. The customer notice clock starts when the incident is declared
SEV2	High	A control failed and could have exposed data, or production degraded for some customers	Incident lead within the hour	Contained the same day. Reviewed within five business days
SEV3	Moderate	One account, device or dependency affected, and no data was reached	A ticket, picked up the next business day	Closed inside the remediation window your policy states
SEV4	Event	A security event triaged and found not to be an incident: a scanner finding with no sign of use, failed sign ins, a phishing email nobody clicked	Nobody is woken. The row is the record of the triage	Closed at triage, or moved to the vulnerability queue

Post-incident review

One row per review, held within five business days of every SEV1 to SEV3 incident. An incident is closed only when its actions are.

Incident ID	Review date	Attendees	Timeline	Time to detect	Time to contain	What worked	What did not	Actions	Action owner	Due	Closed
INC-107	2026-04-10	Engineering lead, chief technology officer, the engineer who committed the key	Alert 10:12, key deactivated 10:37, CloudTrail search done 11:40, pipeline on short lived credentials 13:05	At commit, by the scanner	25 minutes	The scanner caught the key before the pull request merged, and the runbook for a leaked key was followed as written	The pipeline still used a long lived key a year after the plan said to retire it	Add a pre-commit secret scan to every repository template; retire the last long lived AWS key	Engineering lead	2026-04-10	2026-04-10
INC-112	2026-08-18	Chief technology officer, chief executive officer, support lead	Vendor notice 09:05, token and key revoked 11:00, customers notified 14 August, vendor confirmation and integration resumed 14 August	Two days after the access began, by the vendor	2 hours from the notice	The vendor register listed the help desk with its data and its contact, so the right people were reached at once	The help desk kept secrets customers pasted into tickets, and nothing redacted them	Turn on redaction of strings shaped like Moonrake API tokens in the help desk; add a line to the support signature asking customers never to send tokens	Support lead	2026-08-18	2026-08-18

How to use

Open a row in the Incident log the moment an event is triaged. Write Unknown where nothing is known yet and update the row as the response moves.
Set the severity from the Severity scale sheet. An event that is not an incident stays in the log at SEV4: that row is the evidence it was looked at.
Use the same incident ID on the ticket, the review and any customer notice.
Decide whether customers must be told against your contracts, your published commitments and any law that applies, and record the day the notice was sent.
Hold a written review within five business days of every SEV1 to SEV3 incident and record it on the Post-incident review sheet. Close the incident only when its actions are closed.
Never delete or rewrite a row. Add a dated note to correct one.
If the period had no incidents, keep the SEV4 rows and have management sign the statement of no security incidents in the Security Incident Log document.
Evidence for the auditor: this workbook with rows dated inside the audit period, the tickets behind them, the reviews and any customer notices. The log is read against CC7.3, CC7.4 and CC7.5.

Keeping it honest

Open the row at triage. A log written up after the fact loses the times, and the times are what the review and the auditor read.
Write Unknown when you do not know. Whether customer data was affected is often unclear for hours. Change it once the facts are in, and say how they were established.
Never delete a row. Correct it with a dated note. A row that disappears is harder to explain than any incident in it. A scanner finding closed at SEV4 moves to the vulnerability tracker, and the log row stays.
Keep it as long as the policy says. The data retention policy sets how long security records are kept. The log follows it.

Questions

What should a security incident log contain?

One row per security event or incident with an ID, the day it was detected, who reported it and how, a severity, a category, the systems affected, whether customer data was affected, a short summary, what contained it and when, what removed the cause, what restored service and when, the root cause, whether customers had to be told and when they were, the post-incident review date, an owner and a status.

Do SOC 2 auditors want to see the incident log?

Yes. Incident handling sits in the common criteria, so it is tested on every SOC 2 report. CC7.3 asks whether events were evaluated to decide if they were incidents, CC7.4 whether incidents were contained, fixed and communicated under a defined plan, and CC7.5 whether the company recovered and learned from them. The log is where the auditor starts, and the tickets and reviews behind each row are what it samples.

What counts as a security incident for SOC 2?

An event that could have caused, or did cause, a failure to meet your security commitments: someone reaching data they should not, a control that failed and could have exposed data, or a disruption to the service. Your incident response plan sets the definition and the severity levels, and the auditor tests you against the definition you wrote. Events you triaged and closed as not an incident still belong in the log.

What if we had no incidents during the period?

Keep the log anyway. The rows for events you triaged and closed at the lowest level show that events were evaluated, and a statement signed by management that no security incidents were identified during the period is evidence too. The template includes that statement. The auditor reads it beside your alert history and tickets, so sign it only when they support it.

How long should incident records be kept?

For the period your data retention policy sets for security records, and at least long enough to cover every audit period they are evidence for. Contracts and the law can require longer for some records, which is why the number belongs in the retention policy rather than in the log.

Is an incident log the same as an incident response plan?

No. The incident response plan says how an incident is declared, handled and reported before anything happens. The log is the record of each event that did happen and what was done about it. The auditor reads one against the other, so keep the severity levels identical in both.

Sources

TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers.
Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (SP 800-61 Rev. 3) NIST. How incident response fits into risk management.

Get audit-ready without a compliance team.

The readiness assessment is free, with no payment and no card. Star is $2,000 one time to get on the platform and close your gaps. Orbit is $7,800 a year, and your SOC 2 Type 2 audit is included in every contract year. You can be audit-ready starting at about a week.

Take the free assessment

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Why an auditor asks for the log, even when it is empty

Security incident log template, full text

1. How to use this log

2. The severity scale

3. What each column holds

4. Worked example

5. The post-incident review record

6. When there were no incidents

6.1 Statement of no security incidents

7. Keeping the records

8. Fields to complete

The workbook

Incident log

Severity scale

Post-incident review

How to use

Keeping it honest

Questions

Sources

Related

Get audit-ready without a compliance team.