Information
Security
Policy.

1.1 Purpose

This Information Security Policy ("Policy") establishes the principles, responsibilities, and baseline controls that govern how Kazu Technologies protects information assets. It is the authoritative document from which all other security procedures, standards, and guidelines are derived.

The objectives of this Policy are to:

• Protect the confidentiality of client and company data from unauthorized access or disclosure
• Maintain the integrity of information by preventing unauthorized modification or destruction
• Ensure the availability of systems and data for authorized users when needed
• Comply with applicable legal, regulatory, and contractual obligations
• Support client trust by demonstrating a structured and auditable approach to security

1.2 Scope

This Policy applies to:

• All personnel — founders, employees, contractors, and any individuals with access to Kazu systems or data
• All information assets — systems, applications, databases, cloud infrastructure, endpoints, and data in any form
• All environments — production, staging, development, and any systems used to build or operate the Kazu platform
• Third-party vendors — any sub-processor or service provider with access to Kazu systems or client data

1.3 Framework Alignment

This Policy is informed by the NIST Cybersecurity Framework (CSF) — specifically its five core functions: Identify, Protect, Detect, Respond, and Recover. It also reflects requirements under the Florida Information Protection Act (FIPA) and general guidance from the FTC on reasonable data security for businesses.

2.1 Responsibility Matrix

Role	Responsibilities	Accountable for
Security Owner (Founding team designee)	Maintains this Policy; oversees security controls; leads incident response; manages vendor security reviews; reports security posture to leadership	Overall security program
Engineering Lead	Enforces secure development practices; manages cloud infrastructure configuration; reviews access controls; implements technical controls defined in this Policy	Technical controls & platform security
All Team Members	Complete security awareness training; follow acceptable use policies; use approved tools and systems; report suspected incidents promptly	Personal compliance
Third-Party Vendors	Comply with security requirements in vendor agreements; notify Kazu of any breaches affecting Kazu data; provide security documentation upon request	Their systems & sub-processing

2.2 Security Awareness

All personnel must complete security awareness training within 30 days of onboarding and annually thereafter. Training covers phishing recognition, password hygiene, safe data handling, and incident reporting procedures. Completion is tracked and non-compliance is escalated to team leadership.

2.3 Policy Acknowledgment

All personnel and contractors with access to Kazu systems must review and acknowledge this Policy upon onboarding and upon each material revision. Acknowledgment is recorded and retained.

3.1 Principle of Least Privilege

Access to systems, data, and environments is granted on a least-privilege basis — meaning each person is given the minimum level of access necessary to perform their role. Access rights are reviewed at least quarterly and revoked immediately upon role change or departure.

3.2 Authentication Requirements

• Multi-factor authentication (MFA) is mandatory for all internal systems, cloud infrastructure consoles, version control systems, and any system containing client data
• Passwords must be at least 16 characters, unique per service, and managed using an approved password manager
• Shared credentials are prohibited. All access must be traceable to an individual account
• Default or vendor-supplied credentials must be changed before any system goes live

3.3 Privileged Access

Privileged access (e.g., production database access, cloud root accounts, administrative roles) is restricted to a named minimum set of individuals. Privileged actions must be logged. Production access must never be used for development or testing activities.

3.4 Remote Access

All remote access to Kazu's internal systems must occur over encrypted channels (VPN or equivalent). Public Wi-Fi networks must not be used to access production systems or client data without VPN active.

3.5 Offboarding

Upon departure or contract termination, all system access must be revoked within 24 hours. This includes: SaaS application accounts, cloud platform access, version control, email, and any shared credentials the individual may have held.

4.1 Data Classification

Classification	Examples	Handling requirements
Confidential	Client data, credentials, encryption keys, financial records, PII	Encrypted at rest & in transit; access logged; never stored on personal devices
Internal	Internal documentation, source code, product roadmaps, vendor contracts	Access restricted to team members; not shared publicly without review
Public	Marketing content, public documentation, press releases	Standard handling; approved for public distribution

4.2 Encryption Standards

• Data in transit: TLS 1.2 minimum (TLS 1.3 preferred) for all data transmitted over public networks
• Data at rest: AES-256 or equivalent for all stored Confidential data, including database volumes and backups
• Encryption keys: Managed through a dedicated key management service; keys are rotated at least annually and never stored in source code
• Email: Sensitive data must not be transmitted via unencrypted email; use secure file transfer mechanisms for Confidential data

4.3 Data Handling & Transfer

• Client data must never be used in development or testing environments unless fully anonymized or synthetically generated
• Data exports must be authorized, logged, and transferred only to approved destinations
• Physical documents containing Confidential data must be securely destroyed when no longer needed
• Client data must not be stored on personal devices, USB drives, or unapproved cloud storage services

4.4 Backup & Recovery

All production data must be backed up at minimum daily, with backups encrypted and stored in a geographically separate location from the primary data. Backup restoration is tested at least quarterly. Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets are defined in the Availability Policy.

5.1 Endpoint Security Requirements

All devices used to access Kazu systems or handle Confidential data must meet the following baseline requirements:

• Full-disk encryption enabled (FileVault for macOS, BitLocker for Windows, or equivalent)
• Automatic screen lock after no more than 5 minutes of inactivity, with password required to unlock
• Operating system and software kept up to date; critical security patches applied within 7 days of release
• Reputable endpoint security software (antivirus/EDR) installed and active
• Personal devices used for work must meet equivalent security standards (BYOD requires Security Owner approval)

5.2 Cloud Infrastructure Security

• Cloud environments follow the shared responsibility model of the provider
• All cloud resources are deployed via Infrastructure-as-Code (IaC) to ensure consistent, auditable configuration
• Security groups and firewall rules follow deny-by-default; only necessary ports and protocols are open
• Cloud console access is MFA-protected; root/owner accounts are used only in documented break-glass scenarios
• All cloud resource configurations are reviewed for compliance with CIS Benchmarks at least quarterly

5.3 Network Security

• Production environments are isolated from development and staging environments via separate network segments or accounts
• Network traffic is monitored for anomalies; alerting is configured for unusual access patterns or volumes
• All inbound internet-facing services are protected by a Web Application Firewall (WAF) or equivalent
• DDoS protection is enabled at the infrastructure layer

5.4 Approved Software & Services

Team members must use only approved software, SaaS tools, and cloud services for work purposes. The Security Owner maintains a list of approved tools. Use of unapproved ("shadow IT") tools to process Confidential data is prohibited.

6.1 Secure Development Lifecycle (SDLC)

Security is integrated into every phase of the software development lifecycle:

• Design: Security and privacy requirements are considered during feature design. Threat modeling is conducted for significant new features or architectural changes
• Development: Developers follow OWASP Top 10 guidelines
• Review: All code changes require peer review before merging. Security-sensitive changes receive additional scrutiny
• Testing: Automated security scanning (SAST/DAST) is integrated into the CI/CD pipeline. Findings above a defined severity threshold block deployment
• Deployment: Changes to production follow a defined change management process

6.2 Dependency Management

• Third-party libraries and dependencies are inventoried and monitored for known vulnerabilities
• Critical and high-severity dependency vulnerabilities are remediated within 7 days of disclosure
• Dependencies are sourced from official, reputable package repositories only

6.3 Secrets Management

• API keys, tokens, passwords, and other secrets must never be hardcoded in source code or committed to version control
• All secrets are stored in a dedicated secrets manager
• Secrets are rotated at least annually and immediately upon suspected compromise
• Version control repositories are scanned for accidentally committed secrets on every push

6.4 Penetration Testing & Vulnerability Management

Kazu conducts or commissions vulnerability assessments at least annually, and penetration testing at key milestones. Findings are remediated according to:

Severity	Remediation Target
Critical	Within 24 hours
High	Within 7 days
Medium	Within 30 days
Low / Informational	Next scheduled release cycle

7.1 Incident Classification

Severity	Definition	Initial response
P1 · Critical	Active breach, ransomware, complete service outage, confirmed data exfiltration	Immediate — within 1 hour
P2 · High	Suspected breach, significant service degradation, unauthorized access detected	Within 4 hours
P3 · Medium	Anomalous activity, failed intrusion attempts, non-critical system outage	Within 24 hours
P4 · Low	Policy violations, minor anomalies, non-impacting security events	Within 72 hours

7.2 Response Steps

• Detect & Report: Any team member who suspects a security incident must report it to the Security Owner immediately
• Contain: Isolate affected systems to prevent spread; preserve evidence; do not attempt to "clean up" before forensic review
• Assess: Determine scope, impact, and whether client data or regulated data is involved
• Notify: Affected clients are notified as promptly as practicable. Florida FIPA requires notification within 30 days for breaches affecting Florida residents
• Recover: Restore systems from clean backups; verify integrity before returning to service
• Post-Incident Review: A written post-mortem is completed within 14 days of resolution, identifying root cause and corrective actions

8.1 Vendor Security Management

Before onboarding any vendor with access to Kazu systems or client data, the Security Owner conducts a security review assessing:

• The vendor's data handling and security practices (e.g., SOC 2 report, security questionnaire)
• The sensitivity and volume of data the vendor will access
• The vendor's breach notification procedures and contractual obligations

All vendors with access to Confidential data must sign a Data Processing Agreement (DPA) or equivalent contractual security addendum prior to access being granted.

8.2 Ongoing Vendor Monitoring

• Critical vendors are reviewed annually
• Vendors must notify Kazu within 48 hours of any security incident that may affect Kazu or its client data
• Vendor access is revoked immediately upon contract termination

8.3 Regulatory Compliance

Requirement	Applicability	Kazu's Approach
Florida FIPA	All Florida resident data	Breach notification, reasonable safeguards, vendor contracts
FTC Act (Section 5)	All US operations	Reasonable security program; no deceptive practices
CAN-SPAM	Commercial email	Opt-out mechanism, honest headers, physical address in emails
CCPA/CPRA	California residents	Privacy Policy rights, B2B exemption applied; rights requests honored
GDPR (where applicable)	EU/UK data subjects	Addressed in DPA; SCCs or equivalent transfer mechanism
SOC 2 (future)	Enterprise clients	Controls framework designed for future SOC 2 Type II audit

8.4 Policy Exceptions

Any exception to a requirement in this Policy must be documented, risk-assessed, approved by the Security Owner, and reviewed at least quarterly. Exceptions are not permanent — they must have a defined remediation plan and end date.