Instant Strata
Sign in

Legal documents

Information Security Policy

Effective: 12 November 2026·Last updated: 12 November 2026

This Information Security Policy sets out how Instant Strata (we, us, our) protects the confidentiality, integrity, and availability of our information and the information customers entrust to us.

It is an internal governance policy. It applies to Instant Strata people and systems. It is not a customer contract. Customer-facing rules sit in our Terms and Conditions, Privacy Policy, and AI Usage Policy.

Leadership has approved this version. We review it at least once a year, and sooner if threats, systems, or legal obligations change in a material way.

Questions about these legal documents? Contact privacy@instantstrata.com.au.

1. Purpose

We run software that holds scheme records, account data, and other business information. If that information is lost, altered without authority, or seen by the wrong people, customers and individuals can be harmed, and Instant Strata can be harmed.

This policy exists so everyone who works on Instant Strata knows the baseline we expect, how we manage risk, and what happens when something goes wrong.

2. Scope

This policy covers:

  • all Instant Strata directors, employees, contractors, and temporary workers who can access our systems or information
  • systems we operate or control for Instant Strata, including production, staging, development, admin tools, laptops, cloud accounts, source code, and business SaaS
  • customer and scheme data stored or processed in Instant Strata, including personal information and, where connected, Consumer Data Right (CDR) banking data
  • third parties who process Instant Strata information under contract, to the extent our agreements require them to meet equivalent controls

It applies wherever the work is done: office, home, or elsewhere.

3. Leadership commitment

Instant Strata’s leadership is accountable for information security. Leadership will:

  • approve this policy and material updates
  • provide enough people and budget to run the controls described here
  • accept residual risk where treatment is incomplete, and record that decision
  • require staff and contractors to follow this policy
  • support incident response and regulatory notification when needed

Day-to-day ownership of the security program sits with the person designated as Information Security Lead (currently the founder / engineering lead unless leadership names someone else in writing).

4. Roles and responsibilities

4.1 Leadership

  • approve policy and major exceptions
  • oversee risk posture at least annually
  • decide on material incident communications and legal notifications

4.2 Information Security Lead

  • maintain this policy and related standards
  • run the risk register and track treatments
  • coordinate access reviews, vendor reviews, and incident handling
  • make sure staff know how to report issues

4.3 Engineering and operations

  • build and run technical controls (auth, logging, backups, patching, secure development)
  • keep production changes reviewed and reversible where practical
  • limit production access to people who need it

4.4 Managers

  • make sure their people complete required training
  • request and remove access when roles change
  • escalate suspected incidents quickly

4.5 All personnel

  • follow this policy and related standards
  • use only approved accounts and tools for Instant Strata work
  • protect credentials and devices
  • report suspected incidents, lost devices, and policy breaches without delay
  • complete security awareness training when asked

5. Security objectives

We aim to:

  • keep unauthorised people out of production systems and customer data
  • detect and respond to security events in a useful time
  • preserve the integrity of scheme records and financial data we store
  • keep the product available within our operational capacity, with backups we can restore
  • meet our privacy, contractual, and (where applicable) CDR security obligations

6. Risk posture and risk management

Instant Strata is a cloud software company. Our main information assets are customer scheme records, authentication and access data, connected Microsoft workspace data used inside the product, bank feed / CDR data where customers connect accounts, source code, infrastructure credentials, and business records.

Typical threats we plan for include credential theft, phishing, misconfigured cloud services, vulnerable dependencies, insider misuse, vendor outages or breaches, malware on endpoints, and mistakes during change or support work.

Potential harm includes privacy harm to individuals, financial loss or trust accounting errors for schemes, service disruption for managers, regulatory exposure, and damage to Instant Strata’s reputation and contracts.

We keep a simple risk register. For each material risk we record the asset, threat, likelihood, impact, current controls, planned treatment, owner, and status. Leadership reviews the register at least annually, and after material incidents or architecture changes.

Risks may be treated by reducing them, sharing them (for example through contracts or insurance), avoiding the activity, or accepting them. Only leadership may accept high residual risk.

7. Asset management

We maintain an inventory of material information assets, including:

  • cloud projects and environments (application hosting, database, workers, DNS, object storage)
  • source code repositories and CI/CD
  • identity providers and admin consoles
  • laptops and other Instant Strata-managed devices
  • business SaaS that holds Instant Strata or customer data

Each material asset has an owner. When an asset is retired, we revoke access, remove or archive data as required, and update the inventory.

Company devices should use disk encryption, automatic screen lock, and current OS updates. Personal devices used for Instant Strata admin work must meet the same baseline if leadership allows BYOD for that role.

8. Data classification and handling

We classify information so people know how carefully to handle it.

8.1 Classes

  • Public: already published by Instant Strata (marketing site, public docs).
  • Internal: ordinary business information not for public release (roadmaps, internal chat, non-sensitive ops notes).
  • Confidential: customer content, scheme records, personal information, credentials, security tooling output, commercial contracts.
  • Restricted: secrets and keys; production database exports; CDR data and derived banking feeds; security incident files; anything that could cause serious harm if leaked.

8.2 Handling rules

  • Public: no special controls beyond normal publishing review.
  • Internal: Instant Strata accounts only; do not post publicly.
  • Confidential: need-to-know access; encrypt in transit; store in approved systems; do not put in personal email or unmanaged drives.
  • Restricted: least privilege; no local copies unless approved and short-lived; no use in non-production unless scrubbed or synthetic; log access where practical; delete or de-identify when no longer needed.

Customer scheme records and CDR data are at least Confidential, and CDR data is Restricted. Do not mix Restricted data into demos, tickets, or AI prompts unless the work requires it and minimisation has been applied.

9. Access control

Access to Instant Strata systems follows least privilege and need to know.

  • People get unique user identities. Shared human logins for production admin are not allowed.
  • Authentication for Instant Strata staff tools and cloud admin should use strong authentication, including multi-factor authentication where the provider supports it.
  • Customer product access uses Instant Strata’s authenticated sessions and scheme or organisation role checks. Customers decide who in their organisation may access each scheme, within the product’s role model.
  • Privileged access (production database, cloud root/owner, secret stores) is limited to named people, reviewed regularly, and used only for authorised work.
  • Joiners get access approved for their role. Movers have access adjusted. Leavers lose access promptly, including cloud, code, email, and SaaS.
  • We review privileged and production access at least quarterly, and after role changes.
  • Service accounts and API keys are owned, scoped narrowly, rotated when people leave or when compromise is suspected, and not committed to source control.

10. Acceptable use

Instant Strata systems and data are for Instant Strata business. Personnel must not:

  • attempt to access schemes, accounts, or datasets they are not authorised to see
  • share passwords, MFA devices, or session tokens
  • install unapproved remote-access or exfiltration tools on company devices
  • use customer data for personal purposes, unrelated marketing, or training public AI models
  • disable security controls without an approved exception
  • store Restricted data in personal cloud accounts, personal email, or chat tools that are not approved for that class of data

Using AI tools for Instant Strata work is allowed only in line with section 16 and the AI Usage Policy. Customer and CDR data must not be pasted into consumer AI products that Instant Strata has not approved as a subprocessor for that purpose.

11. Cryptography and secrets

We protect data in transit with TLS for external connections to Instant Strata services.

Data at rest in our primary database and object storage relies on provider-managed encryption at rest, unless a specific system needs additional application-level encryption (for example OAuth refresh tokens).

Secrets live in approved secret stores or environment configuration for the relevant environment. They must not be checked into git, pasted into tickets, or shared over insecure channels.

Encryption keys and signing secrets are rotated on a planned schedule and after suspected exposure.

12. Secure development and change management

We build Instant Strata with security in mind from the start of a change, not only at the end.

  • Code changes go through version control. Production changes are reviewed by someone other than the sole author where practical.
  • We prefer automated tests and staged rollout for risky changes.
  • We keep dependencies reasonably current and watch for known vulnerable packages.
  • We do not put real Restricted customer or CDR data into local developer machines or shared staging unless there is a clear need and access is controlled. Prefer synthetic or scrubbed data in non-production.
  • Infrastructure and permission changes follow the same change discipline as application code.
  • Emergency changes are allowed to restore service or contain an incident, then documented afterwards.

13. Operations: logging, monitoring, patching, malware

Production systems should produce logs that help us investigate access and failures. Security-relevant logs include authentication events, admin actions, and access to Restricted data where the platform can record it.

We retain operational and security logs long enough to investigate incidents and meet legal needs, then dispose of them.

We apply security patches to systems we control in a timely way, prioritising internet-facing and privileged components.

Endpoints used for Instant Strata admin work should run current OS security updates and reputable malware protection where available for that platform.

We limit outbound exposure of production data. Database exports and backups are treated as Restricted.

14. Backup and continuity

Customer data in our primary database is backed up using our hosting provider’s backup facilities, supplemented by any Instant Strata-operated export process leadership requires.

We periodically confirm that restores work for critical systems. Recovery priorities favour authentication, core scheme data, and connected financial feeds over nice-to-have features.

Continuity planning covers loss of a cloud region or vendor, loss of key staff access, and ransomware or destructive incidents. We keep break-glass access procedures documented for leadership.

15. Supplier and vendor management

Instant Strata relies on cloud and SaaS vendors (for example application hosting, database hosting, background jobs, email delivery, monitoring, and AI inference).

Before we put Confidential or Restricted data with a vendor, we check that the vendor is suitable for the purpose, that the contract covers confidentiality and security expectations, and that we know where processing may occur.

Material vendors are listed in our inventory. We review them when we renew, when their role expands, or after a vendor incident that could affect us.

Vendors that process CDR data or other Restricted data must not use that data for their own product training or advertising, except as our contract and customer notices allow for providing the Instant Strata service.

16. Artificial intelligence

Instant Strata uses third-party AI APIs inside the product to help with search, summarisation, extraction, drafting, and financial analysis. Details for customers are in the AI Usage Policy.

From a security perspective:

  • only approved AI providers may receive Instant Strata prompts that include customer or CDR content
  • we send task-relevant excerpts, not bulk dumps, and we minimise directly identifying fields where practical before sending CDR excerpts
  • we do not use customer or CDR data to train Instant Strata’s own models, and we contractually restrict providers from using identifiable customer scheme records to train public models
  • AI outputs that include or derive from Restricted data are handled as Restricted or Confidential in Instant Strata
  • staff must not paste Restricted data into personal or unapproved AI tools

17. Human resources and training

Access to Instant Strata systems is granted only after leadership (or a delegated manager) approves the person’s role.

Personnel with access to Confidential or Restricted data complete security awareness training at onboarding and at least annually. Topics include phishing, access handling, incident reporting, acceptable use, and (for people who may touch CDR data) CDR-specific handling rules in section 20.

Confidentiality obligations continue after access ends, as set out in employment or contractor agreements.

18. Incident response

A security incident is any event that actually or possibly compromises the confidentiality, integrity, or availability of Instant Strata information or systems. Examples: lost laptop with production access, exposed secret, ransomware, unauthorised scheme access, misdirected data export, vendor breach affecting our data.

18.1 Reporting

Anyone who suspects an incident must report it immediately to the Information Security Lead (and to leadership if the Lead is unavailable). Customers and users can report security issues to privacy@instantstrata.com.au or the support channel published on our site.

Do not attempt risky forensics yourself if you are unsure. Preserve evidence: do not wipe devices or destroy logs until the Lead says so.

18.2 Handling

The Information Security Lead (or delegate) will:

  • triage and classify severity
  • contain the issue (revoke keys, isolate accounts, take systems offline if needed)
  • investigate scope and root cause
  • recover service and harden controls
  • decide, with leadership, whether notification is required under the Notifiable Data Breaches scheme, CDR rules, contracts, or other law
  • communicate with affected customers when appropriate
  • record the incident and lessons learned

18.3 After-action

Material incidents produce a short written summary: what happened, what data or systems were affected, what we did, what we will change, and whether notifications went out. We use that to update controls and this policy if needed.

19. Privacy and other legal obligations

Information security supports our Privacy Policy and the Australian Privacy Principles. Personal information must be collected and used for Instant Strata’s stated purposes, secured against unauthorised access, and destroyed or de-identified when no longer needed (subject to law and customer retention duties for scheme records).

Where Instant Strata holds or processes CDR data, section 20 applies in addition to the rest of this policy.

If legal obligations conflict, we escalate to leadership and seek advice rather than quietly ignoring a control.

20. CDR data security

This section applies when Instant Strata obtains, holds, or processes Consumer Data Right data (including banking account, balance, and transaction data obtained through an accredited provider such as Fiskil) for scheme financial monitoring and related Instant Strata features.

It is intended to meet the information security policy expectations described in Schedule 2, clause 1.3 of the Competition and Consumer (Consumer Data Right) Rules 2020, and to support Privacy Safeguard 12. Instant Strata’s participation model (for example CDR representative or sponsored arrangements) may place some CDR obligations on our principal or sponsor as well as on us. We still apply these controls to CDR data in our environment.

20.1 CDR risk posture

CDR data in Instant Strata is Restricted. Exposure could reveal scheme financial positions, payment counterparties, and other sensitive commercial detail. Harm can include privacy harm, financial misuse, reputational damage to managers and owners corporations, and regulatory action.

Threats include unauthorised Instant Strata user access, staff or contractor misuse, cloud misconfiguration, compromised credentials, insecure non-production copies, oversharing to AI or other vendors, and failure to delete data after consent ends.

20.2 CDR data environment

The CDR data environment includes the systems and processes that receive CDR data from our CDR provider, store it, display it, analyse it, back it up, log access to it, and delete or de-identify it. Today that centres on Instant Strata’s application servers, background workers, primary database, and approved AI inference path for minimised excerpts, as described in our CDR data flow documentation.

20.3 Practices and controls for CDR

  • Collect and use CDR data only for the consented Instant Strata purposes (scheme bank connection and financial monitoring and analysis for authorised users).
  • Store CDR data in the primary production database with encryption in transit and at rest, scheme or organisation access controls, and least-privilege service access.
  • Do not store bank passwords or data-holder login secrets (we never receive them).
  • Authenticate Instant Strata users and enforce role-based access before showing CDR data.
  • Use multi-factor authentication for staff and privileged access to the CDR data environment’s admin surfaces where supported.
  • Give staff unique IDs; restrict admin privileges; log and monitor security-relevant events.
  • Minimise CDR data sent to AI providers; redact or substitute direct identifiers where practical; do not use CDR data to train models.
  • Keep CDR data out of non-production unless scrubbed, synthetic, or otherwise approved under least privilege.
  • On consent withdrawal, expiry, or when CDR data is no longer required, stop retrieval and delete or de-identify CDR data we hold, except where law requires retention of a limited record (for example proof that deletion occurred).
  • Include CDR handling in security training for people who can access the CDR data environment.
  • Assess and contract vendors that touch CDR data; monitor material vendor issues.
  • Review CDR security controls at least annually, and when the CDR environment or threat landscape changes in a material way.

20.4 CDR incidents

Incidents involving CDR data follow section 18, with explicit assessment of CDR consumer harm and any notice obligations under the CDR regime and our participation arrangement. We will also coordinate with our CDR provider where the arrangement requires it.

21. Exceptions

If someone needs an exception to this policy, they ask the Information Security Lead in writing: what rule, why, for how long, what compensating controls, and what risk remains. Leadership approves exceptions that affect Restricted data or production admin access. Exceptions are time-bounded and recorded in the risk register.

22. Compliance and enforcement

Compliance with this policy is mandatory for people in scope. We may check compliance through access reviews, configuration reviews, vendor reviews, and incident investigations.

Breaches may lead to removal of access, contractor termination, disciplinary action, or other steps available under law and contract. We may also notify customers or regulators when required.

Parts of this policy are made externally enforceable through vendor contracts, staff agreements, and customer terms where relevant (for example acceptable use and security expectations).

23. Review and maintenance

The Information Security Lead reviews this policy at least annually. An earlier review is required after a material security incident, a major product or infrastructure change, a new regulatory obligation (including new CDR participation), or a leadership request.

The current approved version is published for Instant Strata personnel and, where we choose to make it available, at /legal/information-security. Prior versions are retained for audit.

24. Document control

Title: Instant Strata Information Security Policy

Version: 1.0

Effective date: 12 November 2026

Last reviewed: 12 November 2026

Next review due: on or before 12 November 2027 (or earlier if section 23 triggers a review)

Approved by: Instant Strata leadership

Owner: Information Security Lead

Contact: privacy@instantstrata.com.au

25. Related documents

  • Privacy Policy (/legal/privacy)
  • Terms and Conditions (/legal/terms)
  • AI Usage Policy (/legal/ai-usage)
  • CDR data flow diagram (internal / partner assurance pack)
  • Risk register and incident records (internal)

← All legal documents