Skip to main content

Incident Response Plan

Product: Nquiry - Investigation Management Platform Last Updated: January 30, 2026 Version: 1.0 Owner: Joe Etherage (Founder)

1. Purpose​

This plan establishes procedures for detecting, responding to, and recovering from security incidents affecting Nquiry. It ensures compliance with FedRAMP IR (Incident Response) controls and protects customer data.

2. Scope​

This plan covers:

  • Nquiry web application (app.nquiry.ai)
  • AWS infrastructure (Cognito, RDS, S3, Amplify)
  • Customer data (investigations, evidence, user accounts)
  • Landing page (nquiry.ai)

3. Incident Classification​

Severity Levels​

LevelNameDescriptionResponse TimeExamples
P1CriticalActive breach, data exfiltration, system compromiseImmediate (< 1 hour)Unauthorized data access, ransomware, credential compromise
P2HighSecurity vulnerability exploited, service degradation< 4 hoursSQL injection attempt, DDoS attack, authentication bypass
P3MediumSuspicious activity, potential vulnerability< 24 hoursFailed login spikes, unusual API patterns, phishing attempts
P4LowMinor security event, policy violation< 72 hoursSingle failed login, minor misconfiguration, spam

Incident Categories​

  • Unauthorized Access - Breach of authentication/authorization controls
  • Data Breach - Unauthorized disclosure of customer data
  • Malware - Malicious software detected in systems
  • Denial of Service - Service availability impact
  • Insider Threat - Malicious or negligent insider activity
  • Phishing/Social Engineering - Attempts to obtain credentials
  • Vulnerability Exploitation - Active exploitation of known/unknown vulnerability

4. Roles and Responsibilities​

Incident Response Team​

RoleResponsibilityPrimary Contact
Incident CommanderOverall response coordination, decisions, communicationsJoe Etherage
Technical LeadInvestigation, containment, remediationJoe Etherage (+ Claude Code for implementation)
Communications LeadCustomer/stakeholder notificationsJoe Etherage

Note: As a solo founder operation, Joe serves all roles. As the team grows, responsibilities will be delegated.

External Contacts​

EntityWhen to ContactContact Method
AWS SupportInfrastructure issues, suspected AWS compromiseAWS Console → Support
US-CERTP1/P2 incidents affecting federal customersus-cert.cisa.gov
Legal CounselData breach notification requirementsTBD
Cyber InsurancePotential covered incidentTBD (policy pending)

5. Detection Sources​

Automated Monitoring​

SourceWhat It DetectsAlert Method
CloudWatch SyntheticsApplication availability (uptime)CloudWatch Alarm → Email
SentryApplication errors, exceptionsSentry Dashboard + Email
AWS CloudTrailAWS API activity, unauthorized actionsCloudWatch Logs (pending)
CognitoFailed authentications, suspicious loginsCloudWatch Metrics
Application Audit LogsUser actions, data access patternsaudit_log table

Manual Detection​

  • Customer reports (support@nquiry.ai)
  • Security researcher reports
  • Routine log review
  • Third-party breach notifications (e.g., credential dumps)

6. Response Procedures​

Phase 1: Detection & Triage (0-30 minutes)​

  1. Acknowledge alert - Confirm incident is real (not false positive)
  2. Classify severity - Assign P1-P4 based on impact
  3. Document initial findings - Create incident ticket with:
    • Date/time detected
    • Detection source
    • Initial assessment
    • Affected systems/data
  4. Escalate if P1/P2 - Immediate action required

Phase 2: Containment (30 min - 4 hours)​

Immediate containment options:

ActionCommand/LocationWhen to Use
Disable user accountCognito Console → Users → DisableCompromised account
Revoke all sessionsCognito → User → Sign out globallySession hijacking
Block IP addressAWS WAF (when enabled)Active attack source
Disable API keyIAM Console → Users → Security credentialsLeaked credentials
Enable maintenance modeAmplify → Environment variables → MAINTENANCE_MODE=trueActive exploitation
Isolate RDSModify security group to deny allDatabase compromise
Disable S3 bucketS3 → Block public access + deny policyData exfiltration

Do NOT:

  • Delete logs or evidence
  • Restart systems before capturing state
  • Communicate externally before internal alignment

Phase 3: Investigation (Ongoing)​

  1. Preserve evidence

    • Export CloudTrail logs
    • Export application audit logs
    • Snapshot affected RDS instance
    • Capture CloudWatch logs
    • Document timeline

  2. Determine scope

    • What data was accessed/exfiltrated?
    • Which users/organizations affected?
    • What was the attack vector?
    • Is the attacker still present?

  3. Root cause analysis

    • How did the incident occur?
    • What controls failed?
    • Was this preventable?

Phase 4: Eradication & Recovery​

  1. Remove threat

    • Patch vulnerability
    • Remove malware
    • Reset compromised credentials
    • Revoke unauthorized access

  2. Restore services

    • Verify systems are clean
    • Restore from backup if needed
    • Re-enable disabled services
    • Monitor for recurrence

  3. Validate recovery

    • Test application functionality
    • Verify data integrity
    • Confirm security controls active

Phase 5: Post-Incident​

  1. Conduct retrospective (within 5 business days)

    • What happened?
    • What went well?
    • What could improve?
    • Action items

  2. Update documentation

    • This incident response plan
    • Runbooks for specific scenarios
    • Security controls

  3. Implement improvements

    • Address root cause
    • Enhance detection
    • Update training

7. Notification Requirements​

FedRAMP Requirements​

Incident TypeNotification TimelineNotify
Significant incident (P1)Within 1 hourUS-CERT, Affected agency
Data breach affecting federal dataWithin 1 hourUS-CERT, Affected agency
Other security incidents (P2)Within 24 hoursAffected agency

US-CERT Reporting: https://us-cert.cisa.gov/report

HIPAA Breach Notification Requirements​

Per proposed 2026 HIPAA Security Rule:

Notification TypeTimelineRecipient
Business Associate → Covered EntityWithin 24 hoursCovered Entity (customer)
Covered Entity → Affected IndividualsWithin 60 daysAffected individuals
Covered Entity → HHSWithin 60 days (or immediately if >500 individuals)HHS Secretary
Covered Entity → MediaIf >500 residents in a stateLocal media

Critical: Nquiry is a Business Associate. Upon discovery of a breach involving PHI, we must notify the Covered Entity (our customer) within 24 hours. This is a significant reduction from the previous 60-day requirement.

Breach Notification Checklist:

  1. ☐ Confirm breach involves unsecured PHI
  2. ☐ Identify affected Covered Entity customers
  3. ☐ Prepare breach notification with required elements:
    • Nature of breach and PHI involved
    • Date of breach and discovery
    • Steps taken to mitigate harm
    • Steps individuals should take
    • Contact information for questions
  4. ☐ Send notification within 24 hours of discovery
  5. ☐ Document notification sent (date, recipient, content)
  6. ☐ Provide follow-up information as investigation continues

Customer Notification​

SituationTimelineMethod
PHI breach - unauthorized access/disclosure of PHIWithin 24 hoursEmail to Covered Entity (customer)
Data breach - confirmed unauthorized access to customer dataWithin 72 hoursEmail to affected users + in-app banner
Service disruption - extended outage (> 4 hours)During incidentStatus page (when available)
Security advisory - recommended customer actionWithin 24 hoursEmail to all users

Notification Template (Data Breach)​

Subject: Security Notice - Action Required

Dear [Customer Name],

We are writing to inform you of a security incident that may have affected your data.

What happened:
[Brief, factual description]

What information was involved:
[Types of data potentially affected]

What we are doing:
[Actions taken to address the incident]

What you can do:
[Recommended actions - e.g., change password, enable MFA]

For more information:
Contact us at security@nquiry.ai

We sincerely apologize for any concern this may cause.

Joe Etherage
Founder, JE Vectors LLC (Nquiry)

8. Evidence Preservation​

What to Preserve​

  • CloudTrail logs (90 days retained by default)
  • Application audit logs (audit_log table)
  • CloudWatch logs
  • RDS snapshots
  • S3 access logs
  • Cognito authentication logs
  • Network flow logs (if enabled)

Preservation Procedure​

# Export CloudTrail logs to secure bucket
aws cloudtrail lookup-events --start-time <incident_start> --end-time <incident_end> > cloudtrail_export.json

# Create RDS snapshot
aws rds create-db-snapshot --db-instance-identifier invapp-dev-postgres --db-snapshot-identifier incident-YYYY-MM-DD

# Export audit logs
psql $DATABASE_URL -c "COPY (SELECT * FROM audit_log WHERE created_at >= '<start>' AND created_at <= '<end>') TO STDOUT WITH CSV HEADER" > audit_log_export.csv

Chain of Custody​

Document for each piece of evidence:

  • What was collected
  • When it was collected
  • Who collected it
  • Where it is stored
  • Hash/checksum for integrity

9. Communication Templates​

Internal Status Update​

INCIDENT UPDATE - [Severity] - [Date/Time]

Status: [Investigating | Contained | Resolved]
Affected: [Systems/customers]
Current actions: [What's being done]
Next update: [Time]

Executive Summary (Post-Incident)​

INCIDENT SUMMARY

Incident ID: INC-YYYY-MM-DD-XXX
Severity: [P1-P4]
Duration: [Start] to [End]
Impact: [Users/data affected]
Root cause: [Brief description]
Resolution: [Actions taken]
Follow-up: [Planned improvements]

10. Runbooks​

Runbook: Compromised User Account​

  1. Disable user in Cognito Console
  2. Revoke all sessions (sign out globally)
  3. Check audit_log for user's recent activity
  4. Identify any data accessed/modified
  5. Reset password (force password change)
  6. Notify user of compromise
  7. Review how credentials were compromised
  8. Re-enable account after user verification

Runbook: Suspected Data Breach​

  1. Immediately: Assess scope - what data, which customers
  2. Within 1 hour: If federal data involved, notify US-CERT
  3. Create RDS snapshot for evidence
  4. Export relevant audit logs
  5. Identify attack vector
  6. Contain (block access, patch vulnerability)
  7. Prepare customer notification
  8. Engage legal counsel for notification requirements
  9. Document everything for compliance

Runbook: DDoS Attack​

  1. Check CloudWatch for traffic patterns
  2. Enable AWS Shield (if not already)
  3. Configure WAF rate limiting rules
  4. If using CloudFront, enable additional DDoS protections
  5. Consider enabling Amplify WAF
  6. Monitor and adjust rules as attack evolves
  7. Document attack patterns for future prevention

11. Testing & Maintenance​

Plan Testing​

ActivityFrequencyNext Due
Tabletop exercise - Walk through scenarioQuarterlyQ2 2026
Technical drill - Practice containment proceduresAnnuallyQ3 2026
Plan review - Update contacts, proceduresAnnuallyJanuary 2027

Tabletop Scenarios​

  1. Scenario A: Customer reports unauthorized access to their investigation
  2. Scenario B: Security researcher reports SQL injection vulnerability
  3. Scenario C: AWS notifies of compromised IAM credentials
  4. Scenario D: Ransomware detected on development machine

12. Quick Reference​

Emergency Contacts​

ContactPhoneEmail
Joe Etherage (Incident Commander)[REDACTED]joe@nquiry.ai
AWS SupportConsoleaws.amazon.com/support
US-CERT(888) 282-0870us-cert.cisa.gov/report

Critical Commands​

# Check recent audit logs
psql $DATABASE_URL -c "SELECT * FROM audit_log ORDER BY created_at DESC LIMIT 50"

# List Cognito users
aws cognito-idp list-users --user-pool-id $COGNITO_USER_POOL_ID

# Disable Cognito user
aws cognito-idp admin-disable-user --user-pool-id $COGNITO_USER_POOL_ID --username <email>

# Create emergency RDS snapshot
aws rds create-db-snapshot --db-instance-identifier invapp-dev-postgres --db-snapshot-identifier emergency-$(date +%Y%m%d-%H%M%S)

Revision History​

VersionDateAuthorChanges
1.02026-01-30Joe EtherageInitial version
1.12026-02-04ClaudeAdded 24-hour BA breach notification per proposed 2026 HIPAA Security Rule

References​