Contingency Management Plan

1. Purpose

The Contingency Management Plan of Goa Human Rights Commission defines the actions, responsibilities, and procedures to be followed in the event of an incident, disruption, or disaster affecting the website. The objective is to minimize downtime, protect data integrity, ensure continuity of critical services, and restore normal operations as quickly as possible.

2. Scope

This plan covers all incidents that may impact the availability, integrity, confidentiality, or performance of the website and its supporting infrastructure, including servers, networks, databases, applications, content, and third-party services.

3. Types of Contingencies Addressed

Infrastructure failures — server crashes, storage failure, power outages, network loss.
Software failures — application errors, database corruption, failed deployments.
Security incidents — hacking, defacement, malware, ransomware, denial-of-service (DoS/DDoS) attacks, data breaches.
Human errors — accidental deletion, misconfiguration, unauthorized changes.
Natural disasters — fire, flood, earthquake, or other events affecting the data centre or office.
Third-party failures — hosting provider outage, CDN failure, external API failure, domain/DNS issues.
Data loss — partial or complete loss of website content or user data.

4. Severity Classification

Level	Description	Recovery Target (RTO)	Data Loss Tolerance (RPO)
P1 – Critical	Website completely down, security breach, data loss	≤ 2 hours	≤ 1 hour
P2 – High	Major feature unavailable, significant performance degradation	≤ 8 hours	≤ 4 hours
P3 – Medium	Partial feature outage, limited impact	≤ 1 working day	≤ 1 working day
P4 – Low	Minor issues, cosmetic errors	≤ 5 working days	Not applicable

5. Incident Response Workflow

Detection: Monitoring tools, user reports, or internal teams detect the incident.
Logging: Incident is logged with timestamp, symptoms, reporter, and severity.
Notification: Incident response team and relevant stakeholders are notified as per the escalation matrix.
Assessment: Severity is classified and impact analyzed.
Containment: Immediate steps are taken to contain the incident and prevent further damage (e.g., isolating affected systems, blocking malicious traffic).
Communication: A temporary holding page or status message is published where appropriate, and stakeholders are kept informed.
Recovery: Restoration procedures are executed — restore from backup, failover to secondary site, redeploy applications.
Verification: The restored website is tested for functionality, integrity, and security before being brought back online.
Resolution: Normal operations resume; stakeholders informed.
Post-Incident Review: Root cause analysis, lessons learned, and preventive measures are documented.

6. Backup and Recovery

6.1 Backup Strategy

Full backup: Weekly.
Incremental backup: Daily.
Database backup: Every 6 hours.
Configuration and code backup: On every change (version controlled).
Backups stored in at least two geographically separated locations.
Backups encrypted at rest and in transit.
Backup integrity verified monthly through restore testing.

6.2 Retention

Daily backups retained for 30 days.
Weekly backups retained for 3 months.
Monthly backups retained for 1 year.
Annual backups retained for 5 years or as per statutory requirements.

7. Failover and Redundancy

Critical services shall be deployed with high availability and, where feasible, across multiple availability zones or a primary–secondary architecture.
DNS configurations shall support rapid failover to a standby environment.
Load balancers shall be configured to reroute traffic in case of server failure.
A static fallback page shall be available to display a maintenance message if the main website is unreachable.

8. Communication Plan

Internal communication during incidents shall use a pre-defined channel (phone tree, messaging group, ticketing system).
External communication to users shall be through the website status page, official social media handles, and email where applicable.
Messages shall be clear, factual, and free of speculation.
Periodic updates shall be issued during prolonged incidents (at minimum every 2 hours for P1 incidents).

9. Roles and Responsibilities

Role	Responsibility
Incident Manager	Coordinates the overall response, decisions, and communications.
Web Information Manager	Primary owner of website continuity, liaises with management.
IT / Infrastructure Team	Executes technical recovery — servers, network, database.
Security Team	Handles security incidents, containment, forensic analysis.
Content Team	Updates status page, notifications, and user communications.
Vendor / Hosting Provider	Provides support as per SLA during outages affecting their services.

10. Testing and Drills

Backup restore tests shall be conducted monthly.
A full disaster recovery drill shall be performed at least once a year.
Tabletop exercises simulating different scenarios shall be held every 6 months.
Findings from tests shall be documented and fed back into the plan.

11. Post-Incident Review

Within 7 working days of incident resolution, a formal post-incident review shall be completed, covering:

Timeline of events.
Root cause analysis.
Effectiveness of the response.
Impact assessment.
Corrective and preventive actions.
Updates required to this Contingency Management Plan.

12. Plan Maintenance

This plan shall be reviewed at least once every 12 months, or whenever significant changes occur in infrastructure, technology, organizational structure, or threat landscape. All revisions shall be approved by the competent authority and communicated to the concerned teams.