Incident Response and Management Policy¶
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; upon material change to contracts or law
Notification timelines
Notification timelines to customers, partners, and regulators are not fixed by this policy; they follow each customer contract and applicable law (see Notification).
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. | Sandeep AC | — |
| 1.0 | 2026-10-15 | Initial effective release. | Sandeep AC | Sandeep AC |
Purpose¶
This policy establishes how Cloudnaut identifies, reports, contains, investigates, resolves, and learns from information security incidents, and how it meets its obligations to customers and authorities when an incident affects them. Operational steps are defined in the Incident Response Procedure.
Scope¶
This policy covers security incidents affecting:
- Cloudnaut personnel, endpoints, accounts, repositories, and corporate systems.
- Customer information, credentials, systems, or environments accessed by Cloudnaut personnel or affected by Cloudnaut deliverables.
- Suppliers and subcontractors acting for Cloudnaut.
When an incident occurs inside a customer-owned environment, the customer’s incident response process governs the response in that environment. Cloudnaut’s role is to report promptly to the customer, contain within the access Cloudnaut holds, preserve evidence, and support the customer’s investigation as the contract requires. Cloudnaut does not take ownership of incident response for customer infrastructure unless the contract expressly assigns it.
Definitions¶
- Security event: an observable occurrence relevant to security (for example an alert or failed login).
- Security incident: an event, or series of events, that has compromised or is reasonably likely to compromise the confidentiality, integrity, or availability of Cloudnaut or customer information or systems.
- Personal data breach: an incident involving unauthorized processing, disclosure, alteration, loss, or destruction of personal data.
- Near miss: an event that could have become an incident but did not; near misses are reported so controls can improve.
Examples are listed in the awareness training module (section 8).
Roles and responsibilities¶
| Role | Responsibilities |
|---|---|
| All personnel | Report suspected incidents and near misses immediately; follow containment instructions; preserve evidence; keep incident details confidential. |
| Incident Manager (Security Owner by default) | Classifies severity; coordinates response; maintains the incident record; decides on escalation; leads post-incident review. A primary and deputy are designated by management and recorded in the internal incident contact list. |
| Engagement Lead | Notifies the affected customer’s designated contact per contract; coordinates with the customer’s incident process. |
| Management | Approves external communications and notifications; makes business decisions (for example suspending a service); is informed of all Severity 1 and 2 incidents. |
| Legal adviser (internal or external, engaged as needed) | Advises on regulatory and contractual notification obligations. |
Policy¶
- Reporting. Every suspected incident is reported without delay through the reporting channel in the procedure. Personnel must not investigate beyond what is needed to contain, and must not delete evidence.
- Classification. The Incident Manager assigns a severity using the severity matrix and records the incident.
- Containment and eradication. Containment actions are proportionate and, within customer environments, agreed with the customer unless immediate action is needed to stop serious harm and is within Cloudnaut’s authorized access.
- Evidence preservation. Logs, messages, and affected artifacts are preserved, with a record of who collected what and when.
- Credential response. Exposed or suspected-exposed credentials, keys, and tokens are revoked or rotated immediately, and the owning customer is informed if they are customer credentials.
- Communication. External communication about an incident is made only by management or a person they authorize.
- Records. Every incident, including near misses, is recorded in the incident register.
- Post-incident review. Severity 1 and 2 incidents receive a documented post-incident review with corrective actions tracked to closure; lower severities are reviewed as the Incident Manager decides.
- Testing. The incident process is exercised at least annually (for example a tabletop exercise), and the result is recorded.
Notification¶
Cloudnaut notifies affected customers, partners, and authorities within the timelines required by the applicable customer contract and law. This policy deliberately does not fix a timeline:
- Customer notification timelines: as set in each customer contract or security addendum, recorded per engagement.
- Regulatory notification (for example CERT-In reporting under the Information Technology Act directions, or personal data breach notification under the Digital Personal Data Protection Act, 2023 and its rules): as required by law, with applicability and timelines confirmed with legal advice.
- Where no contractual timeline exists, Cloudnaut informs the affected customer without undue delay after confirming that customer information or systems are affected.
The Engagement Lead keeps the notification contacts and contractual timelines for each engagement in the internal engagement record.
Exceptions¶
No exceptions are permitted to the duty to report. Other deviations from the procedure during an active incident are recorded in the incident record with the reason.
Records¶
Incident register, incident reports, evidence logs, notification records, post-incident reviews, corrective-action tracking, and exercise records. These are held internally with restricted access and are not published on this site.