Incident Response
Table of contents Show Hide
Incident response
GoSmarter maintains a documented incident response process designed for dual use:
- operational execution by our internal team
- evidence for customer and auditor due diligence
The process is aligned to common expectations from ISO 27001 incident management controls and UK Cyber Essentials principles.
Scope and objectives
This plan covers security incidents affecting:
- customer data confidentiality, integrity, or availability
- the GoSmarter API, frontend, AI processing services, database, storage, and message infrastructure
- authentication and authorisation controls (Entra ID, RBAC, managed identity)
Objectives:
- detect and contain incidents quickly
- reduce customer and business impact
- meet legal and contractual notification obligations
- learn from incidents and improve controls
What we monitor
The following monitoring is configured and verified in our infrastructure:
- SQL audit logging: Authentication attempts (successful and failed), permission changes, schema changes, and backup/restore operations are logged to Azure Log Analytics
- Application telemetry: Request performance, errors, and exceptions tracked via Azure Application Insights
- Threat detection: Microsoft Defender for SQL is enabled in production: detects SQL injection attempts, anomalous access patterns, and potential vulnerabilities
- Budget and capacity alerts: Budget and capacity alerts detect unusual resource consumption
These signals are triaged as potential incidents when they indicate unauthorised access, data exposure risk, service compromise, or sustained service degradation.
Detection capabilities
| Signal | Source | What it detects |
|---|---|---|
| Failed logins | SQL audit logs | Brute-force attempts, credential stuffing |
| Permission changes | SQL audit logs | Unauthorised privilege escalation |
| Anomalous queries | Defender for SQL | SQL injection, unusual data access patterns |
| Application errors | Application Insights | Service failures, unexpected exceptions |
| Resource anomalies | Azure cost alerts | Unusual compute or storage usage |
Roles and responsibilities
Incident response is coordinated through the following roles:
- Incident Owner (Primary): Chief Product Officer
- Technical Responders: engineering staff responsible for impacted components
- Communications Lead: coordinates customer and stakeholder messaging via email
- Approver for regulator contact: Incident Owner with leadership/legal input as required
If the primary owner is unavailable, the most senior available engineering leader assumes incident command and records handover decisions.
Severity classification
GoSmarter uses four severity levels:
| Severity | Definition | Typical examples |
|---|---|---|
| Critical | Active or confirmed high-impact security event with material customer impact | Confirmed data breach, active compromise, widespread outage from malicious activity |
| High | Significant security risk or service impact requiring urgent response | Credible unauthorised access attempt, major security control failure |
| Medium | Contained or limited-impact incident with no evidence of broad compromise | Isolated suspicious activity, limited component disruption |
| Low | Security-relevant event requiring tracking and remediation but minimal impact | Policy violation, low-risk alert requiring investigation |
Response time SLAs
GoSmarter tracks incident handling against the following internal SLAs.
| Severity | Acknowledge and assign owner | Begin technical triage | Target containment | Customer update cadence |
|---|---|---|---|---|
| Critical | 15 minutes | 30 minutes | 4 hours | Initial customer update within 4 hours, then every 4 hours until stable |
| High | 1 hour | 2 hours | 1 business day | Initial customer update within 1 business day, then daily |
| Medium | 4 business hours | 1 business day | 3 business days | Updates at major milestones or at least every 3 business days |
| Low | 1 business day | 2 business days | 10 business days | Included in standard support/compliance reporting unless risk changes |
Because GoSmarter currently operates without a formal 24/7 on-call rota, incidents raised outside business hours follow a lightweight emergency escalation path. Critical incidents still target acknowledgement within 60 minutes out of hours.
Incident response lifecycle
- Identify: Validate alerts, open an incident record, assign an owner, and classify severity.
- Contain: Restrict access, isolate affected components, rotate credentials/tokens, and block malicious traffic or workflows.
- Eradicate: Remove root cause (code/configuration vulnerability, compromised credential, misconfiguration).
- Recover: Restore normal operation with heightened monitoring and validation.
- Review: Complete root cause analysis, corrective actions, and evidence package.
Notification and communication
- Customer communication channels: direct email notifications to affected customers
- Internal communication channels: internal incident coordination channel and internal email updates
- Status page: not currently used as a primary incident communication channel
For confirmed personal data breaches, GoSmarter targets customer notification within 72 hours of confirmation.
For confirmed personal data breaches that meet UK GDPR notification thresholds, GoSmarter targets regulator notification within 72 hours of becoming aware.
Regulatory escalation (UK GDPR / ICO)
GoSmarter assesses each confirmed personal data breach for regulatory notification requirements. Where UK GDPR thresholds are met, notification to the UK ICO is prepared without undue delay and, where applicable, within 72 hours of becoming aware.
The Incident Owner approves regulator escalation and coordinates final submission with leadership/legal review.
Evidence and retention
- Standard operational telemetry retention is 30 days in Log Analytics unless configured otherwise
- Incident-specific evidence (exported logs, timelines, decisions, customer communications, corrective actions) is retained for 24 months
- Evidence is stored in controlled-access repositories for audit support
Incident notification
GoSmarter operates a documented incident response process with defined severity levels, ownership, escalation, and communication expectations.
For confirmed personal data breaches, we target customer notification within 72 hours of confirmation. Where legal thresholds are met, we escalate for regulator notification in line with UK GDPR requirements.
Customer incident communications are sent via direct email.
Post-incident
For High and Critical incidents, GoSmarter performs a post-incident review that includes:
- timeline of events and response decisions
- root cause analysis
- impact assessment (customers, data, services)
- corrective and preventive actions with owners and target dates
- customer-facing summary where relevant
Post-incident actions are tracked to completion.
Testing and continual improvement
- Incident response tabletop exercise cadence: yearly minimum
- Lessons learned are incorporated into runbooks, monitoring, and preventive controls
- Material updates to the response process are reflected in this trust centre documentation
Alignment to common standards
This process is designed to align with common expectations from:
- ISO 27001 incident management control areas (policy, reporting, assessment, response, and learning)
- Cyber Essentials themes of secure configuration, access control, malware protection, and monitoring-based response
Key points for your security team
- SQL auditing enabled: Audit groups track authentication, permissions, schema changes, and data access
- Defender for SQL in production: Active threat detection for SQL injection and anomalous access
- Application-level monitoring: Full telemetry via Application Insights
- Incident evidence retention: 24 months for case evidence and investigation artifacts
- Incident notification target: 72 hours from confirmed personal data breach
Request evidence
If you need details on our incident response procedures for your security assessment, please contact us directly.