Create an incident contact chain
Before a server or application incident, agree who monitors alerts, who can declare an incident, who approves production changes and who contacts the business owner. Record primary and backup contacts, phone numbers in the secure runbook, and the support coverage window. Do not put private contact details or credentials in a public repository.
For Indian organizations, the CERT-In directions and related FAQs are relevant material to review with the organization’s legal and security teams. Determine whether a specific incident and entity are within scope, which reporting obligations apply and who is accountable for reporting. This operational guide is not a substitute for that assessment.
Keep useful evidence
List the relevant cloud audit events, operating-system logs, application errors, deployment records and network or firewall events. Make sure timestamps can be correlated and log access is restricted. Check applicable retention requirements with the responsible team, and test that an investigator can retrieve logs without using the affected administrator account.
If compromise is suspected, preserve evidence and coordinate containment with the incident lead. Do not delete logs or make a broad cleanup change before understanding its impact on investigation. Document who performed each action and when.
Connect response to recovery
Decide when to isolate a workload, rotate credentials, restore from a known-good backup and validate the application. Rebuilding a server alone may leave compromised credentials, scheduled tasks or an unsafe application dependency in place. Rehearse a restore and use a representative transaction to check the service after recovery.
Agree the managed-service scope
Ask for supported accounts, monitoring, escalation, response hours, change authority and exclusions. Clouvenix can discuss managed infrastructure services; reporting and business decisions remain with the parties assigned those responsibilities in the engagement.