Information Security & Incident Response Policy

Effective Date: January 1, 2025

1. Purpose

This Information Security & Incident Response Policy describes how Summit Digital Innovations protects customer data, prevents security breaches, and responds to security incidents. Our goal is to maintain the confidentiality, integrity, and availability of all customer information.

2. Scope

This policy applies to:

All Summit Digital Innovations systems, applications, and infrastructure
All customer data stored, processed, or transmitted by our platform
All employees, contractors, and third-party service providers
All security incidents, regardless of severity

3. Security Principles

3.1 Confidentiality

Customer data is accessible only to authorized users and staff:

Role-Based Access Control (RBAC): Users have access only to companies and data they are authorized to view
Least Privilege: Users are granted the minimum permissions necessary to perform their job
Need-to-Know: Internal staff access is limited to those who require it for support or operations

3.2 Integrity

Data is protected from unauthorized modification or corruption:

Audit Logging: All data changes are logged (see Audit Log Retention Policy)
Soft Deletes: Financial records are never hard-deleted; they are marked as voided/deleted
Input Validation: All user input is validated and sanitized to prevent injection attacks

3.3 Availability

Our platform is designed for high availability and resilience:

Uptime Target: 99.9% uptime (excluding scheduled maintenance)
Redundancy: Multi-zone database replication and failover
Backups: Continuous backups with 4-hour disaster recovery (see Backup Retention Policy)
Status Page: Real-time status monitoring at status.summit-di.com

4. Data Protection Measures

4.1 Encryption

Data in Transit:

TLS 1.3 (minimum TLS 1.2) for all web traffic
HTTPS enforced for all connections (no HTTP allowed)
Certificate pinning for API connections

Data at Rest:

AES-256 encryption for all database data
AES-256 encryption for all file storage (S3)
Encrypted backups (see Backup Retention Policy)
Key management via AWS KMS (Key Management Service)

Passwords and Secrets:

Passwords hashed with bcrypt (never stored in plaintext)
Multi-factor authentication (MFA) codes never logged or stored
API keys and secrets encrypted in configuration

4.2 Authentication and Access Control

User Authentication:

Password Policy: Minimum 9 characters, uppercase, lowercase, special character
Multi-Factor Authentication (MFA): Available via email or SMS; required for platform admins
Session Management: Sessions expire after 24 hours of inactivity
Brute Force Protection: Account lockout after 5 failed login attempts

Access Control:

RBAC: Role-based permissions (Platform Admin, Company Admin, Accountant, Bookkeeper, Staff)
Company Scoping: All queries scoped by company_id to prevent cross-company data access
Firm Scoping: All queries scoped by firm_id to prevent cross-firm data access
Permission Checks: Every route enforces permission decorators before data access

4.3 Network Security

Infrastructure:

Hosting: Heroku (Salesforce) with isolated application dynos
Database: Heroku Postgres with private networking (no public internet access)
Firewall: Application-level firewall rules restrict access to authorized IPs
DDoS Protection: Cloudflare or Heroku Shield for DDoS mitigation

API Security:

Rate Limiting: API requests limited to prevent abuse (100 requests/minute per user)
Authentication: JWT tokens with short expiration (24 hours)
Input Validation: All API inputs validated against strict schemas
CORS: Cross-origin requests restricted to authorized domains

4.4 Application Security

Secure Coding Practices:

Input Validation: All user input sanitized to prevent XSS, SQL injection, command injection
Parameterized Queries: All database queries use parameterized statements (no string concatenation)
Output Encoding: All HTML output encoded to prevent XSS attacks
CSRF Protection: Anti-CSRF tokens required for all state-changing operations

Dependency Management:

Vulnerability Scanning: Automated scanning for known vulnerabilities in dependencies
Update Policy: Security patches applied within 7 days of disclosure
Minimal Dependencies: Only essential third-party libraries are used

4.5 Third-Party Security

We carefully vet all third-party service providers:

Stripe: PCI DSS Level 1 certified payment processor
Plaid: SOC 2 Type II certified bank connectivity provider
Twilio: SOC 2 Type II certified SMS delivery provider
AWS: SOC 2, ISO 27001, FedRAMP certified infrastructure
Heroku: SOC 2 Type II certified hosting platform

All third-party providers sign Data Processing Agreements (DPAs) and are contractually obligated to maintain security standards.

5. Security Monitoring and Logging

5.1 Continuous Monitoring

We monitor our platform 24/7 for security threats:

Intrusion Detection: Automated alerts for suspicious activity (unusual logins, privilege escalation, data exfiltration attempts)
Anomaly Detection: Machine learning models detect unusual patterns (e.g., login from new location)
Failed Authentication Monitoring: Alerts triggered after multiple failed login attempts
Audit Log Monitoring: Real-time monitoring of sensitive actions (role changes, deletions, exports)

5.2 Security Logging

All security-relevant events are logged (see Audit Log Retention Policy):

Authentication events (logins, logouts, MFA)
Authorization failures (permission denied)
Data access and modifications
Administrative actions (role changes, user additions)
Security events (account lockouts, suspicious activity)

5.3 Alerting

Security alerts are sent to our incident response team via:

Email: security@summit-di.com
Slack: #security-alerts channel (internal)
PagerDuty: Critical alerts trigger on-call notifications

6. Vulnerability Management

6.1 Vulnerability Scanning

Frequency: Weekly automated scans

Scope:

Application code (SAST - Static Application Security Testing)
Dependencies (known CVEs in third-party libraries)
Infrastructure (network ports, services, configurations)

6.2 Penetration Testing

Frequency: Annual third-party penetration test

Scope:

Web application security (OWASP Top 10)
API security
Authentication and authorization
Network infrastructure

Remediation: All critical and high-severity findings remediated within 30 days

6.3 Responsible Disclosure

We welcome security researchers to report vulnerabilities responsibly:

Contact: security@summit-di.com
Response Time: Initial response within 48 hours
Recognition: Security researchers credited (with permission) on our security page
No Legal Action: We will not pursue legal action against researchers who follow responsible disclosure guidelines

Responsible Disclosure Guidelines:

Report vulnerabilities privately (not publicly disclosed before we can fix them)
Do not access, modify, or delete customer data
Do not perform actions that could degrade service availability
Provide sufficient detail to reproduce the vulnerability

7. Incident Response

7.1 Incident Definition

A security incident is any event that compromises (or threatens to compromise) the confidentiality, integrity, or availability of customer data or systems:

Data Breach: Unauthorized access to customer data
Account Compromise: Unauthorized access to user accounts
Malware: Malicious software detected on our systems
DDoS Attack: Service disruption due to denial-of-service attack
Unauthorized Access: Internal staff accessing data without authorization
Data Loss: Accidental or malicious deletion of customer data

7.2 Incident Response Phases

Phase 1: Detection and Triage (0-1 hour)

Detect: Security monitoring alerts or user report triggers incident
Assess Severity: Classify as Critical, High, Medium, or Low based on impact
Notify Team: Page on-call incident response team
Document: Create incident ticket with initial details

Phase 2: Containment (1-4 hours)

Isolate Threat: Block malicious IPs, revoke compromised credentials, disable affected accounts
Prevent Spread: Ensure threat is contained and cannot spread to other systems
Preserve Evidence: Capture logs, snapshots, and forensic data before containment actions

Phase 3: Investigation (4-24 hours)

Root Cause Analysis: Determine how the incident occurred
Scope Assessment: Identify what data was accessed, modified, or exfiltrated
Timeline Reconstruction: Build timeline of events using audit logs
Impact Assessment: Determine which customers and records were affected

Phase 4: Eradication (24-48 hours)

Remove Threat: Delete malware, close vulnerabilities, patch systems
Verify Clean: Ensure no traces of the threat remain
Update Defenses: Deploy additional security measures to prevent recurrence

Phase 5: Recovery (48-72 hours)

Restore Service: Bring affected systems back online
Restore Data: Restore from backup if data was corrupted or deleted (see Backup Retention Policy)
Monitor Closely: Increased monitoring for 72 hours post-recovery

Phase 6: Post-Incident (72+ hours)

Post-Mortem: Document what happened, what went well, what needs improvement
Customer Notification: Notify affected customers per legal requirements (see 7.3)
Regulatory Reporting: Report breach to authorities if required (see 7.4)
Remediation Plan: Implement long-term fixes to prevent recurrence
Update Policies: Update security policies and procedures based on lessons learned

7.3 Customer Notification

If a security incident affects customer data, we will notify affected customers:

Timing: Within 72 hours of discovery (GDPR requirement)
Method: Email to registered email address + in-app notification
Content:
- Description of the incident
- What data was affected
- What we're doing to address it
- What actions customers should take (e.g., change password, review logs)
- Contact information for questions

7.4 Regulatory Reporting

We will report security incidents to regulatory authorities as required by law:

GDPR (EU): Report to supervisory authority within 72 hours if personal data of EU residents is affected
CCPA (California): Report to California Attorney General if breach affects 500+ California residents
State Data Breach Laws: Report per applicable state laws in the US

8. Employee Security Training

All Summit staff receive security training:

Onboarding: New employees complete security awareness training within first week
Annual Training: All staff complete annual refresher training
Phishing Simulations: Quarterly phishing tests to assess awareness
Role-Specific Training: Engineers receive secure coding training; support staff receive data handling training

9. Physical Security

Our platform is cloud-hosted; we do not maintain on-premises servers:

Data Centers: AWS and Heroku data centers with 24/7 physical security, biometric access, video surveillance
No Local Data: Summit staff do not store customer data on local devices
Device Security: Company laptops require full-disk encryption and strong passwords

10. Business Continuity and Disaster Recovery

We maintain documented procedures for business continuity:

Recovery Time Objective (RTO): 4 hours (system restored within 4 hours of disaster)
Recovery Point Objective (RPO): 5 minutes (up to 5 minutes of data loss in worst case)
Disaster Recovery Plan: Documented procedures for failover to backup region
Annual Testing: Disaster recovery drills conducted annually

See our Backup Retention Policy for complete details.

11. Compliance Certifications

We are committed to achieving industry-standard security certifications:

SOC 2 Type II: (Planned for 2026) - Annual audit of security controls
ISO 27001: (Planned for 2027) - Information security management system certification
GDPR Compliance: Data protection and privacy controls for EU users
CCPA Compliance: Privacy controls for California residents

12. Security Contact and Reporting

To report a security issue or ask security questions:

Summit Digital Innovations Security Team
Email: security@summit-di.com
Response Time: 48 hours for non-urgent, 4 hours for critical
PGP Key: Available upon request for encrypted communication

For Emergencies (Active Breach):

Email with subject line "URGENT SECURITY INCIDENT" — our on-call team is paged immediately.

13. Changes to This Policy

We review and update this policy annually or after significant security incidents. Material changes will be communicated via:

Email notification to active account holders
In-app notice upon next login
Updated effective date on this page

Related Policies: