Why this policy exists.
Kazu operates a cloud-based ERP platform that processes sensitive business data on behalf of its clients. Protecting that data — and the systems that hold it — is a core obligation, not an afterthought.
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
Kazu is currently in a pilot phase, operating at a limited scale as it validates the platform and prepares its QuickBooks Online Integration for review by Intuit. The controls described in this Policy are in effect during the Pilot Phase and will continue to be expanded as Kazu's infrastructure and client base grow. See the Privacy Policy and Terms of Use & DPA for details on data handling during this period.
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.
This Policy is reviewed annually and updated whenever there are material changes to our technology stack, team structure, regulatory environment, or threat landscape.
Who is responsible for what.
Security is a shared responsibility. Every person with access to Kazu systems has a role to play — and that role is defined here.
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.
The right access to the right people.
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.
Kazu applies a zero-trust mindset: no user or system is inherently trusted, even within internal networks. All access is verified, all sessions are logged, and all permissions are time-limited where technically feasible.
Protecting data at every state.
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.
Securing the perimeter — and beyond.
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.
Security built in from the start.
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 |
When things go wrong.
No system is perfectly immune. What matters is how quickly and effectively incidents are detected, contained, and resolved — and how clearly clients and regulators are informed.
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
Under Florida FIPA (Fla. Stat. § 501.171), Kazu must notify affected individuals within 30 days of determining a breach has occurred. If more than 500 Florida residents are affected, the Florida Attorney General must also be notified.
Extending security beyond our walls.
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.
Security as a practice.
Security is everyone's job
No single role owns security. Every team member who touches a system is a layer of defense — or a point of failure. Awareness and habits matter as much as tools.
Default to least privilege
Access expands friction. The less access any person or system holds, the smaller the blast radius of any incident. We start with nothing and grant only what's necessary.
Assume breach
We design systems as if an attacker may already be present — segmenting data, logging activity, and verifying every action. Prevention is the goal; containment is the fallback.