OPERATIONS
Effective February 20, 2026
·
Review February 20, 2027
·
Security Lead
Incident Response Plan
Organization: Aina Design Corp
Applies To: hawaii.mokunet.us · kuleana.ainadesign.org · huikoeaina.ainadesign.org · ainadesign.org
Version: 1.0
Effective Date: February 20, 2026
Next Review: February 20, 2027
Policy Owner: Security Lead
1. Purpose
This plan defines how Aina Design Corp detects, responds to, and recovers from security incidents — including data breaches, unauthorized access, and attacks — to protect student data, preserve platform integrity, and meet notification obligations to district partners and, where required, to students and families.
2. What Constitutes a Security Incident
A security incident is any confirmed or suspected event that:
Results in unauthorized access to student data or platform systems
Compromises the confidentiality, integrity, or availability of education records
Involves misuse of authorized access to student data
Represents a violation of security policy
Is a credible threat or near-miss that warrants investigation
Examples: phishing attack targeting staff credentials, unauthorized database export, exposure of student PII through misconfigured access control, ransomware deployment.
3. Incident Severity Levels
Level
Description
Response Time
P1 — Critical
Active breach; student data confirmed exposed; ransomware active
Immediate (< 1 hour)
P2 — High
Suspected breach; significant unauthorized access; service unavailable
< 4 hours
P3 — Medium
Policy violation; anomalous access; no confirmed data exposure
< 24 hours
P4 — Low
Near-miss; minor policy violation; no access to sensitive data
< 5 business days
4. Incident Response Phases
Phase 1 — Detection and Reporting
Security incidents may be detected via:
Automated alerts from logging and monitoring systems
Report by a staff member, district partner, or user
External notification (e.g., security researcher, law enforcement)
Any person who identifies a potential security incident must report it immediately to the Security Lead at: security@ainadesign.org or via the internal incident reporting channel.
Do not attempt to investigate or remediate independently — report first.
Phase 2 — Triage and Containment
Upon receiving a report, the Security Lead:
1.
Confirms whether a security incident has occurred (within the timeframe for the severity level).
2.
Assigns a severity level.
3.
Takes immediate containment actions to limit further exposure, which may include:
Revoking compromised credentials
Disabling affected services or user accounts
Blocking malicious IP addresses
Isolating affected systems from the network
4.
Documents all actions taken with timestamps.
Containment does not mean deleting evidence. Logs and artifacts are preserved for investigation.
Phase 3 — Investigation
The Security Lead conducts or oversees a full investigation to determine:
What data was accessed, exfiltrated, or modified
Which systems, services, and users were affected
How the incident occurred (root cause)
The timeline of the incident
Whether student education records were involved
All investigation findings are documented in an Incident Report.
Phase 4 — Notification
Internal Notification
All P1 and P2 incidents: notify organizational leadership immediately upon containment.
District Partner Notification (FERPA Breach Notification)
If student education records were or may have been exposed:
Districts are notified within 72 hours of confirmed breach discovery.
Notification includes:
Nature and scope of the incident
Data categories and number of students potentially affected
Steps taken to contain and remediate
Recommended actions for the district
Contact for district questions
Legal and Regulatory Notification
The Compliance Officer assesses whether the incident triggers obligations under:
Hawaii Revised Statutes §487N (data breach notification law)
FERPA (through district notification)
Any contractual notification requirements
Phase 5 — Remediation
After containment and investigation:
1.
Root cause is addressed (patch deployed, misconfiguration corrected, access revoked).
2.
Affected systems are verified clean before returning to production.
3.
Monitoring is enhanced for the affected area.
4.
Staff training is updated if a human error contributed to the incident.
Phase 6 — Post-Incident Review
Within 5 business days of resolution:
A written Post-Incident Report is completed, including:
Timeline of detection, response, and resolution
Root cause analysis
Impact assessment (data, users, services)
Lessons learned
Action items with owners and due dates
The report is stored in audit evidence.
Recurring incidents trigger a review of the relevant policy or control.
5. Evidence Preservation
Security incident evidence (logs, screenshots, configuration snapshots, communications) must be preserved in a designated, access-controlled location for a minimum of 5 years per the Data Retention and Deletion Policy. Evidence must not be deleted, modified, or moved without written authorization from the Security Lead.
6. Communication During an Incident
Audience
Channel
Who Communicates
Internal team
Designated internal channel
Security Lead
District partners
Email to district data governance contact
Data Governance Lead
Families (if required)
Coordinated through the district
District (supported by Aina Design Corp)
Media / public
No public statement without executive approval
Executive Sponsor
7. Annual Testing
The incident response plan is tested annually through a tabletop exercise. The exercise simulates a realistic threat scenario and walks all key personnel through their roles. Findings are incorporated into the next revision of this plan.
8. Review Cadence
This plan is reviewed annually and updated after any declared security incident.
9. Key Contacts
Role
Contact
Security Lead
security@ainadesign.org
Data Governance Lead
privacy@ainadesign.org
General
admin@ainadesign.org
10. Sign-Off
Security Lead: _________________________
Executive Sponsor: _________________________
Date Approved: _________________________