Security Policy

1. Overview and Scope

This Security Policy applies to all systems, infrastructure, data, and personnel involved in the operation of the CEF Core platform. It covers the complete lifecycle of customer data from collection and processing through storage, transmission, and eventual destruction.

CEF Core processes sensitive financial data including loan records, investor account information, general ledger transactions, personally identifiable information (PII), and tax reporting data. The controls described in this policy are designed to meet or exceed the requirements of:

• SOC 2 Type II Trust Service Criteria (Security, Availability, Confidentiality)
• AICPA Generally Accepted Privacy Principles
• NIST Cybersecurity Framework (CSF) 2.0
• GDPR and CCPA data protection requirements
• IRS Publication 1075 (tax data safeguarding)

2. Data Encryption

2.1 Encryption at Rest

All data stored by CEF Core is encrypted at rest using AES-256 (Advanced Encryption Standard with 256-bit keys), the encryption standard approved by the US National Institute of Standards and Technology (NIST) and used by financial institutions worldwide.

• Database: PostgreSQL tablespace encryption with AES-256. All 101 tables across 16 schemas are encrypted.
• Backups: Database backups are encrypted before storage using AES-256-GCM with independent encryption keys.
• File Storage: All uploaded documents and generated reports are encrypted at rest.
• Key Management: Encryption keys are stored separately from encrypted data and rotated on a quarterly schedule.

2.2 Encryption in Transit

All data transmitted to and from CEF Core is protected using TLS 1.3, the latest version of the Transport Layer Security protocol.

• HTTPS Enforcement: All HTTP traffic is redirected to HTTPS. HSTS (HTTP Strict Transport Security) headers are set with a one-year max-age.
• Certificate Management: SSL/TLS certificates are automatically provisioned and renewed via Let's Encrypt with no manual intervention.
• Cipher Suites: Only strong cipher suites are permitted. TLS 1.0, 1.1, and weak cipher suites are explicitly disabled.
• Internal Traffic: Service-to-service communication uses encrypted channels. Database connections require SSL.

2.3 Sensitive Data Handling

• PII Fields: Social Security numbers, tax identification numbers, and bank account numbers receive additional field-level encryption.
• Secrets Management: API keys, database credentials, and JWT signing keys are stored as environment secrets with restricted access.
• Log Sanitization: Sensitive data is automatically redacted from application logs and error messages.

3. Access Controls

3.1 Authentication

• JWT-Based Authentication: All API access requires valid JSON Web Tokens signed with HS256. Access tokens expire after 24 hours; refresh tokens expire after 7 days.
• Multi-Factor Authentication: MFA is required for all administrative accounts. TOTP-based authenticator apps are supported.
• Password Policy: Minimum 12 characters, requiring a mix of uppercase, lowercase, numbers, and special characters. Passwords are hashed with bcrypt (cost factor 12).
• Session Management: Automatic session timeout after inactivity. Concurrent session limits enforced per user role.

3.2 Authorization

• Role-Based Access Control (RBAC): Three defined roles (Admin, Treasury, Staff) with granular permissions controlling access to every endpoint and data operation.
• Principle of Least Privilege: Users are granted only the minimum permissions necessary to perform their job functions.
• Maker-Checker Workflow: Financial transactions exceeding configurable thresholds require approval from a second authorized user before execution.
• Transaction Limits: Role-based daily and monthly transaction limits prevent unauthorized large-value operations.

3.3 Infrastructure Access

• SSH Key Authentication: Server access requires Ed25519 SSH keys. Password-based SSH login is disabled.
• Separated User Accounts: Dedicated system accounts for application runtime, deployment, and database administration with distinct privilege levels.
• Access Reviews: User access permissions are reviewed quarterly. Inactive accounts are disabled after 90 days.

4. Incident Response

4.1 Incident Classification

Security incidents are classified by severity to determine response urgency and escalation procedures:

4.2 Response Procedures

• Detection: 24/7 automated monitoring with PagerDuty and Slack alerting for anomalous activity, unauthorized access attempts, and system health degradation.
• Containment: Immediate isolation of affected systems, revocation of compromised credentials, and preservation of forensic evidence.
• Eradication: Root cause analysis, vulnerability remediation, and verification that the threat has been fully eliminated.
• Recovery: System restoration from verified backups, gradual service re-enablement, and enhanced monitoring during recovery period.
• Post-Incident Review: Formal incident report within 5 business days, including root cause analysis, timeline, impact assessment, and corrective actions.

4.3 Customer Notification

In the event of a confirmed data breach affecting customer data, CEF Core will notify affected customers within 72 hours of confirmation, in compliance with GDPR Article 33 and applicable US state breach notification laws. Notification includes the nature of the breach, data affected, remediation steps taken, and recommended protective actions for customers.

5. Vulnerability Management

5.1 Vulnerability Scanning

• Dependency Scanning: Automated scanning of all npm dependencies for known vulnerabilities using npm audit on every build.
• Infrastructure Scanning: Regular automated scans of server configurations, open ports, and service versions.
• Code Analysis: Static application security testing (SAST) integrated into the CI/CD pipeline to detect security issues before deployment.

5.2 Penetration Testing

• Annual third-party penetration testing by qualified security firms.
• Testing covers OWASP Top 10 vulnerabilities, API security, authentication bypass, and privilege escalation.
• All findings are remediated according to severity: Critical within 24 hours, High within 7 days, Medium within 30 days, Low within 90 days.

5.3 Patch Management

• Critical Patches: Applied within 24 hours of release for vulnerabilities with known exploits.
• Security Patches: Applied within 7 days for high-severity vulnerabilities.
• Regular Updates: Operating system, runtime, and dependency updates applied on a monthly cycle.
• Node.js LTS: The platform runs on Node.js Long Term Support releases, ensuring timely security patches and stability.

6. Employee Security Training

• Onboarding Training: All new employees complete security awareness training before accessing any production systems, covering data handling procedures, acceptable use policies, and incident reporting.
• Annual Refresher Training: Mandatory annual security training for all personnel covering emerging threats, phishing detection, social engineering awareness, and secure development practices.
• Phishing Simulations: Regular simulated phishing campaigns to test and reinforce employee awareness.
• Secure Development Training: Engineering staff receive specialized training on OWASP secure coding practices, SQL injection prevention, and input validation.
• Background Checks: All employees with access to customer data or production systems undergo background screening.

7. Third-Party Security Assessments

• SOC 2 Type II Readiness: The platform is designed and operated to meet SOC 2 Type II Trust Service Criteria. Independent audit engagement planned for ongoing compliance validation.
• Annual Penetration Testing: Conducted by independent, qualified security firms with expertise in financial services applications.
• Vendor Security Reviews: All third-party vendors and service providers undergo security assessment before integration, including review of their SOC 2 reports, security policies, and data handling practices.
• Risk Assessments: Formal risk assessments conducted annually and whenever significant changes are made to systems, infrastructure, or data processing activities.

Customers may request a summary of our most recent security assessment results by contactingsecurity@cefcore.com.

8. Data Retention and Destruction

8.1 Retention Periods

8.2 Data Destruction

• Data that has exceeded its retention period is permanently destroyed using cryptographic erasure or secure deletion methods.
• Database records are soft-deleted first (marked with is_deleted flag), then permanently purged after the retention period expires.
• Backup media containing expired data is destroyed through certified destruction processes.
• Customers may request data deletion subject to legal retention requirements by contacting our support team.

9. Physical and Infrastructure Security

9.1 Data Center Security

CEF Core infrastructure is hosted in Hetzner Cloud's Ashburn, Virginia data center, which provides:

• 24/7 on-site security personnel and CCTV surveillance
• Biometric access controls and multi-factor physical authentication
• Redundant power supplies with UPS and diesel backup generators
• Environmental monitoring (temperature, humidity, fire suppression)
• N+1 redundancy for all critical infrastructure components

9.2 Network Security

• Firewall: UFW (Uncomplicated Firewall) configured with default-deny policy. Only ports 80, 443, and restricted SSH are open.
• DDoS Protection: Network-level DDoS mitigation provided by the hosting infrastructure.
• Rate Limiting: Application-level rate limiting using token bucket algorithms via Redis to prevent API abuse and brute-force attacks.
• Intrusion Detection: Automated monitoring for anomalous network patterns, failed authentication attempts, and suspicious API usage.

9.3 Backup and Disaster Recovery

• Backup Frequency: Automated daily database backups with continuous WAL (Write-Ahead Log) archiving.
• Recovery Point Objective (RPO): 1 hour maximum data loss in a disaster scenario.
• Recovery Time Objective (RTO): 4 hours maximum time to full service restoration.
• Backup Testing: Automated backup verification and restoration testing to confirm data integrity.
• Geographic Redundancy: Backup copies stored in a separate geographic location from the primary data center.

10. Compliance and Governance

• Policy Review: This security policy is reviewed and updated at least annually, or whenever significant changes occur to the platform, infrastructure, or threat landscape.
• Change Management: All changes to production systems follow a formal change management process including peer review, testing, and approval before deployment.
• Audit Trail: All administrative actions, data access, and system changes are logged in an immutable, tamper-evident audit trail with cryptographic hash chains.
• Regulatory Monitoring: Ongoing monitoring of regulatory changes affecting church extension funds, financial services, and data protection.

11. Responsible Disclosure

CEF Core welcomes responsible disclosure of security vulnerabilities. If you discover a potential security issue, please report it to our security team:

Please provide sufficient detail to reproduce the issue, refrain from accessing or modifying customer data, and allow reasonable time for remediation before any public disclosure.

12. Contact Information

For questions about this security policy, to request security documentation, or to report a security concern: