Incident Response Procedure¶

Organization: Cloudnaut Technologies LLP
Classification: Internal
Document status: Effective
Version: 1.0
Owner: Management / Security Owner
Effective date: 2026-10-15
Review cycle: Annual; after any Severity 1 or Severity 2 incident
Governing policy: Incident Response and Management Policy

Response targets

Response-time targets in this procedure are internal targets. They do not replace notification timelines in customer contracts or law, which are confirmed per engagement.

Document control¶

Role	Name
Prepared by	Management / Security Owner (Cloudnaut)
Reviewed by	Sandeep AC
Approved by	Sandeep AC

Revision history¶

Version	Date	Summary	Reviewed by	Approved by
0.1	2026-10-15	Initial draft: lifecycle steps, severity matrix, report template.	Sandeep AC	—
1.0	2026-10-15	Initial effective release.	Sandeep AC	Sandeep AC

Purpose and scope¶

This procedure gives the step-by-step actions for handling a security incident under the Incident Response and Management Policy. It applies to all personnel and to every incident in that policy’s scope.

How to report¶

Report immediately — do not wait until you are sure.

Contact the Incident Manager (contact details in the internal incident contact list) and your Engagement Lead, by phone or direct message.
Follow up in writing through the security reporting channel in the internal incident contact list, with what happened, when, which systems/data/customers may be involved, and what you have done so far.
If the incident involves a customer environment, also follow the customer’s reporting instructions provided at onboarding.

Do not discuss the incident in public or shared customer channels, on social media, or with people who do not need to know.

Response lifecycle¶

1. Detect and report¶

Sources: personnel reports, endpoint protection alerts, CI/CD scanning alerts, platform security notifications, customer reports, supplier notifications.
Reporter provides initial facts; Incident Manager acknowledges.

2. Triage and classify¶

Incident Manager confirms whether it is an incident, assigns a severity from the severity matrix, opens an incident record, and assigns an incident ID.
Identify affected customers and look up the contractual notification contact and timeline in the engagement record.

3. Contain¶

Typical actions (choose what applies):

Revoke or rotate exposed credentials, tokens, and keys; remove compromised sessions.
Disable affected Cloudnaut accounts or remove repository/organization membership.
Isolate an affected endpoint from the network (do not power it off unless instructed, to preserve evidence).
For customer environments: inform the customer and agree containment; act unilaterally only within authorized access to stop serious ongoing harm, and inform the customer immediately.

4. Preserve evidence¶

Keep logs, alerts, emails, chat messages, and affected files. Export platform audit logs (for example source-control audit logs, cloud trail logs where Cloudnaut has access).
Record in the evidence log who collected what, when, and where it is stored.

5. Notify¶

Engagement Lead notifies affected customers per contract; management approves wording.
Management, with legal advice, decides on regulatory notifications.
Record every notification (who, when, how, content).

6. Eradicate and recover¶

Remove the cause (malware, misconfiguration, vulnerable dependency, unauthorized access).
Restore from known-good sources; verify endpoint baseline before reconnecting; confirm with the customer before resuming work in their environment.

7. Close and learn¶

Complete the incident report (template below).
For Severity 1 and 2: hold a post-incident review promptly after closure, on a date set by the Incident Manager; record root cause, what worked, what did not, and corrective actions with owners and due dates.
Update policies, training, or controls where the review identifies gaps.

Severity matrix¶

Severity	Description	Examples	Internal target to start response	Escalate to
Severity 1 — Critical	Confirmed compromise or exposure of customer or personal data, or of privileged access to a customer environment; or active attack in progress.	Customer production credentials leaked publicly; ransomware on a customer-work endpoint; confirmed unauthorized access to customer data.	Immediately; Incident Manager engaged within 1 hour	Management and affected customer(s)
Severity 2 — High	Likely compromise or exposure with limited scope, or a significant control failure affecting customer work.	Lost unencrypted device suspected; secret committed to a private repository; malware detected and quarantined on a customer-work endpoint with possible data access.	Same working day	Management; customer if their information may be affected
Severity 3 — Medium	Security event with no evidence of data exposure, contained quickly.	Successful phishing click without credential entry; lost encrypted, locked laptop; policy violation without exposure.	Within 2 working days	Engagement Lead
Severity 4 — Low / near miss	Attempt or weakness with no impact.	Phishing email reported and not clicked; misconfiguration found and fixed before use.	Within 5 working days	Recorded only

When in doubt, classify higher. Severity may be revised as facts emerge; record each change.

Incident report template¶

Copy this template into the incident record. Do not store completed reports on this site.

Field	Entry
Incident ID
Reported by / date and time
Detected how
Incident Manager
Severity (initial → final)
Affected customer(s) / engagement(s)
Affected systems, accounts, repositories
Data involved (classification; personal data yes/no)
Summary of what happened
Timeline (detection, containment, eradication, recovery, closure)
Containment actions taken
Evidence collected and storage location
Notifications made (to whom, when, by whom, contractual deadline)
Root cause
Corrective and preventive actions (owner, due date)
Post-incident review date
Closure approved by / date

Records¶

Incident register (all incidents and near misses), completed reports, evidence logs, notification records, post-incident reviews, and annual exercise records, held internally with restricted access.