Trust Center Information Security Policy
Part of our Trust Center

Information Security Policy

Establishing the principles, framework, and governance structure for protecting the confidentiality, integrity, and availability of information assets at FindTheBreach.

Effective Date: February 23, 2026  |  Last Reviewed: February 23, 2026

Owner: Chief Information Security Officer (CISO), Find The Breach LLC

Review Schedule: Annually or upon significant changes

1 Purpose & Scope

This Information Security Policy ("Policy") establishes the management direction, principles, and framework for protecting the confidentiality, integrity, and availability of all information assets owned, controlled, or processed by Find The Breach LLC ("FindTheBreach," "Company," "we," or "us"). This Policy is aligned with SOC 2 Trust Services Criteria CC1 (Control Environment), ISO/IEC 27001:2022, and NIST Cybersecurity Framework 2.0.

Scope. This Policy applies to:

  • All employees, contractors, consultants, temporary workers, and third-party service providers with access to FindTheBreach information systems or data
  • All information assets including the FindTheBreach SaaS platform, API services, Docker-based container infrastructure, PostgreSQL databases, scanner tool integrations (35+ tools), customer data, scan results, and vulnerability findings
  • All computing environments including production, staging, development, and disaster recovery systems
  • All locations from which FindTheBreach systems are accessed, including remote work environments
  • All forms of information: electronic, physical, and verbal

Violation of this Policy may result in disciplinary action up to and including termination of employment or contract, and may also result in civil or criminal penalties under applicable law.

2 Security Objectives

The information security program at FindTheBreach is designed to achieve the following objectives:

  • Confidentiality: Ensure that information is accessible only to authorized individuals. Customer vulnerability data, scan results, and credentials are encrypted at rest using AES-256-GCM and in transit via TLS 1.3. Access is restricted on a need-to-know basis.
  • Integrity: Safeguard the accuracy and completeness of information and processing methods. All scan results, configuration changes, and user actions are logged in tamper-evident audit trails. Database integrity is enforced through PostgreSQL constraints and transactional consistency.
  • Availability: Ensure that authorized users have reliable and timely access to information and associated assets. The platform maintains a target availability of 99.9% (as defined in our SLA), with automated failover, backup procedures, and disaster recovery capabilities.
  • Accountability: Maintain comprehensive audit trails for all actions performed within the platform. Every API request, administrative action, and scanner execution is logged with user identity, timestamp, source IP, and action details.
  • Compliance: Meet or exceed the requirements of SOC 2 Type II, GDPR, CCPA/CPRA, HIPAA (for applicable customers), and other relevant regulatory frameworks.

3 Roles & Responsibilities

Information security is the responsibility of all personnel. The following roles have specific security responsibilities:

Role Responsibilities
Executive ManagementApprove the information security policy, allocate resources for the security program, set risk appetite, and demonstrate commitment to information security through leadership and example.
Chief Information Security Officer (CISO)Develop, implement, and maintain the information security program. Report on security posture to executive management. Oversee risk assessments, incident response, and compliance activities. Serve as the policy owner.
Engineering & DevOpsImplement security controls in the platform architecture, maintain secure Docker container configurations, manage PostgreSQL database security, enforce secure coding practices, and support vulnerability remediation.
Data OwnersClassify data within their domain, approve access requests, ensure appropriate controls are applied based on classification, and review access permissions quarterly.
All PersonnelComply with this Policy and all supporting security procedures. Complete security awareness training within 30 days of onboarding and annually thereafter. Report suspected security incidents immediately.

4 Risk Management

FindTheBreach maintains a formal risk management process to identify, assess, treat, and monitor information security risks. This process is aligned with SOC 2 CC3 (Risk Assessment) and ISO 31000.

  • Risk Identification: Threats and vulnerabilities are identified through continuous vulnerability scanning (using our own 35+ scanner tool suite), penetration testing, threat intelligence feeds, and internal assessments. The risk register is updated as new threats are identified.
  • Risk Assessment: Each identified risk is evaluated for likelihood and impact using a standardized 5×5 risk matrix. Risk scores incorporate CVSS base scores, EPSS exploit probability, and CISA Known Exploited Vulnerabilities (KEV) catalog data where applicable.
  • Risk Treatment: Risks are treated through one of four strategies: mitigate (apply controls to reduce risk), transfer (insure or contract), accept (document formal acceptance by risk owner), or avoid (eliminate the activity). Risks exceeding the defined risk appetite require executive approval for acceptance.
  • Risk Monitoring: The risk register is reviewed quarterly. Key Risk Indicators (KRIs) are monitored continuously and reported to executive management monthly. Material changes in the risk landscape trigger ad-hoc assessments.

5 Asset Classification & Management

All information assets are inventoried, assigned an owner, and classified according to sensitivity. Asset classification determines the minimum security controls required for handling, storage, transmission, and disposal.

  • Asset Inventory: A centralized asset inventory is maintained covering all hardware (servers, workstations), software (Docker images, application dependencies, scanner tools), data stores (PostgreSQL databases, scan result repositories), and cloud services. The inventory is reviewed quarterly.
  • Classification Levels: Assets are classified as Public, Internal, Confidential, or Restricted (see our Data Classification Policy for detailed handling requirements per level).
  • Asset Lifecycle: Security controls are applied throughout the asset lifecycle — from provisioning through operation to decommissioning. Docker containers are built from hardened base images, scanned for vulnerabilities before deployment, and securely destroyed upon retirement.

6 Access Control

Access to information systems and data is restricted to authorized personnel based on the principles of least privilege and need-to-know. Access control measures are aligned with SOC 2 CC6 (Logical and Physical Access Controls).

  • Authentication: All users must authenticate using strong credentials. Multi-factor authentication (MFA) via TOTP is required for all administrative access, production system access, and customer portal access. API access requires cryptographically signed tokens with defined expiration periods.
  • Authorization: Role-based access control (RBAC) is enforced across the platform. Roles are defined with minimum necessary permissions. Privileged access (administrative, database, infrastructure) requires additional approval and is logged with enhanced audit detail.
  • Password Policy: Passwords must be a minimum of 14 characters, include complexity requirements, and are stored using bcrypt with a minimum cost factor of 12. Password reuse of the last 12 passwords is prohibited.
  • Access Reviews: Access permissions are reviewed quarterly by data owners. Orphaned accounts are disabled within 24 hours of personnel departure. Privileged accounts are reviewed monthly.
  • Session Management: Sessions expire after 30 minutes of inactivity. Concurrent session limits are enforced. Session tokens are invalidated upon logout or password change.

7 Incident Management

FindTheBreach maintains a formal incident response capability to detect, respond to, and recover from security incidents. The incident management process is aligned with SOC 2 CC7 (System Operations) and NIST SP 800-61 Rev. 2. Full details are documented in our Incident Response Plan.

  • Reporting: All personnel are required to report suspected security incidents immediately via the designated incident reporting channel. Anonymous reporting is supported.
  • Classification: Incidents are classified by severity (Critical, High, Medium, Low) based on impact to confidentiality, integrity, and availability of systems and data. Severity determines response timelines and escalation paths.
  • Response: The incident response process follows six phases: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. Critical and High severity incidents trigger immediate assembly of the incident response team.
  • Notification: Affected customers are notified within 72 hours of confirmed data breaches. Regulatory authorities are notified as required by GDPR Article 33, state breach notification laws, and contractual obligations.
  • Post-Incident Review: All incidents classified as Medium or above undergo a formal post-incident review within 5 business days. Root cause analysis findings are tracked to remediation and may trigger updates to this Policy.

8 Business Continuity & Disaster Recovery

FindTheBreach maintains business continuity and disaster recovery plans to ensure the resilience and recoverability of critical platform services, aligned with SOC 2 CC9 (Risk Mitigation) and ISO 22301.

  • Backup Strategy: PostgreSQL databases are backed up daily with point-in-time recovery capability. Backups are encrypted using AES-256-GCM, stored in geographically separate locations, and tested for restorability quarterly.
  • Recovery Objectives: The platform targets a Recovery Time Objective (RTO) of 4 hours and a Recovery Point Objective (RPO) of 1 hour for critical services including the scanning engine, API, and customer portal.
  • Infrastructure Resilience: Docker containers are orchestrated with automated health checks and restart policies. Stateless application containers can be redeployed from versioned images within minutes.
  • Testing: Disaster recovery plans are tested at least annually through tabletop exercises and simulated failover drills. Test results are documented and deficiencies are tracked to remediation.

9 Compliance & Legal Requirements

FindTheBreach is committed to compliance with all applicable legal, regulatory, and contractual requirements relating to information security and data protection.

  • SOC 2 Type II: The information security program is designed to satisfy all five Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy). Independent audits are conducted annually.
  • GDPR & CCPA/CPRA: Personal data is processed in accordance with applicable data protection laws. Data processing agreements are maintained with all sub-processors. Privacy impact assessments are conducted for new processing activities.
  • HIPAA: For customers subject to HIPAA requirements, FindTheBreach executes Business Associate Agreements (BAAs) and implements additional safeguards as required by the HIPAA Security Rule.
  • Cryptographic Standards: All data at rest is encrypted using AES-256-GCM. Data in transit is protected by TLS 1.3. Cryptographic keys are managed through a formal key management process with defined rotation schedules.
  • Audit & Monitoring: Compliance is monitored through continuous automated controls, quarterly internal reviews, and annual independent audits. Non-compliance findings are tracked in the risk register and remediated within defined timelines.

10 Policy Review & Maintenance

This Policy is a living document and will be reviewed and updated to reflect changes in the threat landscape, regulatory environment, business operations, and technology infrastructure.

  • Review Frequency: This Policy is reviewed at least annually by the CISO and approved by executive management. Ad-hoc reviews are triggered by significant security incidents, material changes to the platform architecture, new regulatory requirements, or organizational changes.
  • Change Management: All changes to this Policy follow the formal Change Management Policy. Changes are documented with version history, rationale, and approval records.
  • Communication: All personnel are notified of material changes to this Policy. Updated training is provided where policy changes impact day-to-day operations or security responsibilities.
  • Exception Management: Exceptions to this Policy require written justification, a compensating controls plan, a defined expiration date, and approval from the CISO. Exceptions are documented in the risk register and reviewed quarterly.

Policy Contact

Chief Information Security Officer (CISO), Find The Breach LLC

Email: security@findthebreach.com