Direct answer

Stabilise the application without destroying evidence: preserve web, application, WAF, database, identity and deployment logs; contain the affected application or attack path; rotate exposed secrets; identify unauthorised code, configuration or data changes; remediate the root cause; and return the service to production under heightened monitoring.

When to activate this playbook

Unexpected application, WAF or reverse-proxy alerts. Unauthorised admin activity, file changes, deployments or configuration changes. Suspicious requests coincide with database errors, data access or service instability. Secrets, tokens, credentials or sensitive application data may have been exposed.

First 15 minutes

Open an incident and preserve web, application, WAF, load-balancer and deployment evidence. Contain the attack path using the least destructive approved measure that protects users and evidence. Protect privileged application, deployment, database and cloud identities. Record the application version, deployment state and relevant infrastructure at the time of containment.

First hour

Identify affected routes, accounts, data stores, hosts, containers or cloud resources. Review for unauthorised code, web shells, configuration changes, new accounts, tokens or persistence. Rotate exposed application secrets, keys or credentials through a controlled process. Determine whether sensitive data was accessed, changed or exfiltrated.

First day

Remediate the root vulnerability or misconfiguration and validate the fix in an approved environment. Restore or redeploy from a trusted source and verify integrity before normal traffic resumes. Monitor the application, identity, network and data layers for recurrence. Create follow-up engineering, secure-development, detection and control improvements.

Evidence to preserve

EvidenceWeb server, WAF, reverse-proxy and application logs.

EvidenceDatabase and identity audit logs.

EvidenceDeployment, source-control, CI/CD and configuration history.

EvidenceFile, container, image or host integrity evidence.

EvidenceRelevant secrets, token changes and remediation actions without exposing secret values in the incident record.

Key decision points

Is the attack path still reachable?

Was unauthorised code or persistence introduced?

Were secrets or sensitive data exposed?

Can the service be safely restored from a trusted build and configuration?

Communication discipline

Coordinate security, engineering, operations, product and legal/privacy owners. Avoid publishing exploit details before containment and remediation are complete. Use confirmed technical facts when assessing customer or regulatory notification obligations.

Where Cybatar fits

Web Shield telemetry and posture context linked to incidents. Incident, forensic evidence and remediation-task coordination. Asset, domain, exposure and governance records connected to the affected application. Security reporting for engineering and assurance follow-up.

Claim boundary

Cybatar can collect and coordinate web-security context and response records, but it does not guarantee that every web exploit is detected or blocked, and it does not replace secure application design, code review, WAF/runtime controls or specialist application-security investigation.

Web Shield capabilityhttps://cybatar.co/platform/web-shield Web application security guidehttps://cybatar.co/cybersecurity/web-application-security Web application security solutionhttps://cybatar.co/solutions/web-application-security-operations Capability evidencehttps://cybatar.co/evidence/product-capabilities Incident Response Checklisthttps://cybatar.co/incident-response-checklist Evidence Preservation Checklisthttps://cybatar.co/incident-evidence-preservation-checklist

Web Application Incident Response