Information Security Program

This Information Security Program (“the Program”) sets out how Wizel protects the confidentiality, integrity, and availability of its own systems and the data it processes on behalf of its customers.

Wizel operates an AI-powered email marketing platform for Shopify DTC brands and Klaviyo agencies. In doing so, Wizel acts as a data processor on behalf of its customers (the data controllers), handling brand assets, marketing content, campaign analytics, and, in some cases, customer contact data synced from connected platforms. This Program reflects Wizel’s commitment to handling that data responsibly and to meeting its obligations under the Australian Privacy Act 1988 (including the Notifiable Data Breaches scheme), and, where applicable, the EU/UK GDPR.

The Program is deliberately scaled to the size and risk profile of the business. It favours controls that are real, enforced, and verifiable over aspirational language.

This Program applies to:

• All systems Wizel owns, operates, or controls, including production infrastructure, source code, build pipelines, and administrative tooling.
• All third-party services that store or process Wizel or customer data (e.g. hosting, databases, AI model providers, email platforms, source control).
• All personnel, whether employees or contractors, who access Wizel systems or data.
• All company-owned and personally-owned devices used to access Wizel systems or data.

Asset and data inventory

All personnel and contractors are responsible for following this Program, protecting credentials, reporting suspected incidents promptly, and completing required security practices. Accountability for the Program — including access provisioning, incident response, and the annual review — sits with the founder as security owner.

Where contractors are engaged, their access is governed by the access-control rules below, and they are bound by written confidentiality terms before any access is granted.

Wizel classifies data into three tiers to determine handling requirements.

Secrets (API keys, database credentials, tokens) are managed through environment variables and a dedicated secrets store, never committed to source control. Production credentials are separated from development and never reused across environments.

Wizel applies the principles of least privilege and need-to-know. Access to any system or dataset is granted only where required for a person’s role and is removed when no longer needed.

Authentication

• Multi-factor authentication (MFA) is mandatory on all accounts that support it, including source control, hosting/infrastructure, DNS/CDN, email, and administrative consoles.
• Unique credentials are used for every service; shared logins are prohibited.
• Passwords are generated and stored in a password manager and meet a minimum length-based strength standard, unique per service.
• Administrative and production access is restricted to the smallest possible set of accounts.

Access reviews

• User access reviews for standard (non-administrative) accounts are conducted quarterly, confirming each account still requires its current level of access.
• Privileged and administrative accounts are reviewed at the same quarterly cadence, and additionally whenever a person's role changes.
• Reviews are recorded (date, accounts reviewed, changes made) to provide an audit trail.

Provisioning and offboarding

• Access is granted only after the need is confirmed and, for contractors, after confidentiality terms are signed.
• On departure or end of engagement, all access is revoked within 24 hours — including source control, infrastructure, third-party consoles, and shared services. Associated credentials and tokens are rotated.

All devices used to access Wizel systems or data — whether company-owned or personally-owned — must meet the following baseline controls.

• Administrative access to servers is restricted to authorised accounts using key-based SSH (no password authentication) and MFA-protected provider consoles.
• A content delivery network / reverse proxy sits in front of the application, providing TLS termination, DDoS protection, and a Web Application Firewall.
• All external traffic is served over HTTPS using current TLS (TLS 1.2 minimum, 1.3 preferred). HTTP is redirected to HTTPS.
• Databases and internal components are not directly exposed to the public internet; they are reachable only from the application layer over restricted network paths.
• Default credentials are changed on all systems before use, and unused services and ports are disabled.

In production

• A Web Application Firewall filters common attack patterns aligned to the OWASP Top 10, with rate limiting and bot mitigation on authentication and sensitive endpoints.
• Security response headers are enforced — HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, and Referrer-Policy.
• Sessions are protected with secure, HTTP-only cookies and appropriate same-site settings.

In the codebase

• Input is validated and output encoded to defend against injection and cross-site scripting (XSS); database queries use parameterised / operator-safe patterns.
• Authentication, authorisation, and session management follow established framework practices; access-control checks are enforced server-side on every request.
• Secrets are never hard-coded; they are injected via environment configuration and a secrets store.

In the pipeline

• Dependencies are continuously scanned for known vulnerabilities (including npm audit and automated dependency-update tooling), with remediation prioritised by severity.
• Code is reviewed before changes reach production, and changes are deployed through a controlled pipeline rather than by editing production directly.

Wizel remediates vulnerabilities on a risk-prioritised basis using vendor ratings and CVSS scores.

Where a vulnerability cannot be remediated within target (for example, a fix is unavailable), a compensating control or temporary mitigation is applied and the exception is recorded. For managed services, the underlying platform is patched by the provider; Wizel applies any configuration or version updates within its control on the same timeframes.

• Application, server, and access logs are collected and retained. Authentication events — including failed and unusual login attempts — are logged.
• The CDN / WAF provides visibility into traffic anomalies, blocked attacks, rate-limit violations, and DDoS events, with alerting on significant security events.
• Production errors and abnormal behaviour are monitored so unexpected patterns surface quickly.
• Uptime and health checks alert the team to outages or abnormal service behaviour.
• Notable security and availability events generate alerts for investigation.

Logs are protected against tampering and accessible only to authorised personnel. Detection findings that indicate a possible compromise trigger the incident response process below.

Encryption

• In transit: all data moving between users, the application, third-party services, and infrastructure is encrypted using TLS 1.2 or higher.
• At rest: data stored on infrastructure and endpoints is encrypted at rest. Restricted data such as secrets and tokens is additionally protected and access-controlled.

Backup and recovery

• Production data and critical configuration are backed up on a regular schedule.
• Backups are stored separately from primary systems and are encrypted.
• Restore procedures are tested periodically to confirm backups are usable.
• Retention balances recovery needs with data-minimisation principles.

Data minimisation and retention

• Wizel collects and retains only the data needed to provide the service.
• Customer data is retained per the relevant customer agreement and deleted or returned on request or at the end of the engagement, subject to legal retention requirements.

• Material providers (hosting, databases, AI model providers, connected marketing platforms, source control) are reviewed for appropriate security and privacy commitments, including published security documentation and, where applicable, data processing terms.
• Data shared with AI providers is limited to what is required to generate the requested output; provider terms regarding data use and retention are reviewed and relied upon.
• Access granted to or from third parties follows the least-privilege and offboarding rules above.
• A list of key sub-processors is maintained and made available to customers on request to support their own compliance obligations.

Wizel maintains a defined process for responding to security incidents and suspected data breaches:

1. Identify and report — anyone who suspects an incident reports it to the incident lead immediately.
2. Contain — limit impact (revoke credentials, isolate affected systems, block malicious traffic).
3. Assess — determine what occurred, what was affected, and whether personal information was involved.
4. Eradicate and recover — remove the cause, restore from clean backups where needed, and confirm systems are secure.
5. Notify — carry out notifications per the obligations below.
6. Review — conduct a post-incident review to capture lessons and improve controls.

Breach notification obligations

• Australian Notifiable Data Breaches scheme: where a breach is likely to result in serious harm, Wizel assesses it promptly (and within 30 days of becoming aware) and notifies the OAIC and affected individuals as soon as practicable.
• Customer / contractual notification: as a processor, Wizel notifies affected customers (controllers) without undue delay and, as a target, within 72 hours of confirming a breach affecting their data.
• GDPR (where applicable): where EU/UK personal data is involved, Wizel supports the relevant controller's 72-hour notification obligation.

• Critical systems and data are backed up and recoverable, enabling restoration after data loss, corruption, or infrastructure failure.
• Infrastructure-as-configuration and documented deployment procedures allow the environment to be rebuilt if needed.
• Recovery objectives (target time to restore service and acceptable data-loss window) are defined and reviewed against the backup schedule.
• Much resilience is inherited from managed providers; Wizel's responsibility is to maintain recoverable backups and tested restore procedures.

Personnel maintain current awareness of phishing and social-engineering risks and how to verify unexpected requests, safe credential and secrets handling, secure development practices, and their responsibilities under this Program. Contractors are briefed on relevant security expectations before being granted access. As the team grows, structured onboarding security training will be introduced.

• Production infrastructure resides in data centres that provide physical security, environmental controls, and access management as part of their certified facilities.
• Endpoints are kept physically secure, encrypted, and locked when unattended.
• Restricted data is not stored on portable media or kept locally where avoidable.

• Ownership: the founder owns this Program and is accountable for its maintenance and enforcement.
• Review: the Program is reviewed at least annually, and additionally after any significant change to systems, services, data handling, or organisational structure, or following a material security incident.
• Exceptions: any deviation is documented with the reason, the compensating control applied, the approver, and a review date, and revisited at each Program review.
• Records: access reviews, incident records, exceptions, and review dates are retained to demonstrate the Program is operating.

We would rather tell you what we do not have than let you assume it. Wizel is a small, founder-led company, and this Program is scaled to that reality. As at the effective date above:

• We do not hold a SOC 2, ISO 27001, or equivalent third-party certification, and no audited attestation report is available.
• We have not commissioned an independent third-party penetration test. Our application security relies on the secure-development practices, dependency scanning, and WAF controls described in sections 8 and 9.
• Separation of duties is limited by team size. The founder holds administrative access to production and is also the person who reviews it, which is a recognised limitation of a company of this size rather than a control we claim to operate.
• We do not offer a paid bug bounty, though we welcome and will acknowledge responsible disclosure under the policy below.

We will update this section as the position changes. If your procurement process needs assurance we cannot yet provide, tell us at info@wizel.ai — we would rather have that conversation early than have it come up at renewal.

If you believe you have found a security vulnerability in Wizel, please report it to info@wizel.ai with enough detail for us to reproduce it. We aim to acknowledge within 3 business days and to keep you updated until it is resolved.

Safe harbour

If you make a good-faith effort to comply with this policy during your research, we will treat it as authorised, will not pursue or support legal action against you for it, and will work with you to resolve the issue quickly. To stay within this safe harbour, you must:

• give us a reasonable opportunity to fix the issue before disclosing it publicly, and coordinate the timing with us;
• test only against your own account and data — never another customer's;
• avoid privacy violations, data destruction or exfiltration, service degradation, denial-of-service testing, spam, and social engineering of our people or providers;
• stop as soon as you have confirmed a vulnerability, and delete any data you accessed incidentally; and
• comply with applicable law, and with the terms of any third-party platform involved.

This policy covers Wizel-operated systems only. Issues in a third-party service should be reported to that provider under its own policy.