File: Security & trust
Principle: Clear responsibilities · sensible layers · honest communication
Frameworks: Essential Eight · SOC 2 · ISO/IEC 27001, explained in plain language

How we keep your apps,systems and data safe.

Rendr builds and runs systems that sit close to safety, compliance and money. Security is part of how we design, review and operate every system from the beginning, with responsibilities and controls explained in practical terms.

Request a 15-minute callor write to [email protected]

FILE 01 · THE FUNDAMENTALS

Security in plain language

We keep things simple on purpose: you know what we manage, what you manage and where the boundaries are; protection sits at several levels, including identity, network, application and data; and when something goes wrong you hear it from us first, not last.

01Who can get in

We connect to your existing sign-in wherever possible (for example Microsoft 365 / Entra ID), so your own identity provider controls who can log in
Multi-factor authentication can be required at your end
People only get access to what they need for their role

02How data is stored and sent

Data is encrypted when it is stored
Data is encrypted when it moves between systems
Environments are separated so an issue in one area does not spill into another

03Keys and passwords

API keys and passwords live in secure storage, not in code or spreadsheets
Keys are rotated regularly and whenever staff or vendors change
Access to secrets is logged: who used what, and when

04How the software behaves

We validate what comes into the system instead of trusting it blindly
Limits on how quickly an API can be called reduce abuse and accidents
Sensitive actions, such as changing roles and exporting data, are written to an audit log

05How the infrastructure is set up

Systems run inside private networks, not directly on the open internet
Only a small number of well-defined entry points are exposed
No unnecessary sharing of infrastructure between unrelated clients

06Where it runs

Our managed environment by default. That is what makes monitoring, patching and backups work
Your code and data are yours with full access; leave and everything transfers in a few clicks
Your own enterprise infrastructure on request, scoped on a call

FILE 02 · MONITORING, INCIDENTS, RECOVERY

Operations

Keeping an eye on things

Logs from the systems we manage are collected in one place
Alerts are raised for repeated failures, unusual activity and other signs that something looks wrong
We review every alert and either fix it or record why it is safe to ignore

When something goes wrong

We aim to notice problems before end users do
Someone is clearly responsible for owning the incident and keeping you updated
Stop the bleeding first, then understand what happened
After a major incident, a short review so it is less likely to happen again

Backups and recovery

Data is backed up regularly
Key systems can be restored to a point in time
We test restores for important systems so we do not discover problems in an emergency

Serious security issues don’t wait for sign-off. Up to four hours of emergency remediation is pre-authorised in every agreement, billed at the standard rate, so we can act immediately. Beyond that we talk to you first. The more serious the risk, the faster we move. You always hear about it from us first.

FILE 03 · SYSTEM CONNECTIONS

How we secure integrations

A lot of risk sits around integrations, because they join different systems together. We treat them with the same care as the apps themselves.

Logins to third-party systems

The official, recommended method (for example OAuth) where available
Only the access we need, never “full admin”
Keys and tokens in secure storage, rotated on a schedule

Webhooks and callbacks

We verify that callbacks really come from the expected system
Protection against replayed or duplicated messages
Sensible rate limits so one misconfigured system cannot overload another

Handling API changes

Pinned to known API versions where possible
Tests around important integrations so breaking changes surface early
Changes rolled out with a way to roll back if something misbehaves

FILE 04 · SHARED RESPONSIBILITY

Who looks after what

Rendr looks after

The apps and integrations we design and build
The managed environment we run them in
Patching and updating the software we deliver
Monitoring, logging and responding to issues in those systems

You look after

Which people in your organisation get access, and what they can see
How your laptops, desktops and mobile devices are secured
Your internal policies for using and sharing data
Identity provider settings, including password rules and multi-factor authentication

In short: we keep the platform and data flows secure and healthy. You control who uses them and how your organisation handles data.

FILE 05 · COMPLIANCE

Compliance and reviews

Our security practices are shaped by well-known frameworks, including the Australian Essential Eight, SOC 2 and ISO/IEC 27001, but we explain them in plain language and in the context of your deployment.

If you need to go deeper, we can:

Complete security questionnaires
Provide code and architecture reviews for existing applications
Provide written summaries of our controls and architecture diagrams
Join calls with your security, IT or risk teams to walk through how a deployment will work

Talking about security.

Security questions come up early in a project and again before go-live. We expect that. If you have specific needs for where data lives, who can access it, or how incidents and vulnerability reports are handled, we can usually shape the deployment and operating model to match your standards.

Start: Send an enquiryJason usually replies within minutes during business hours
Step two: Technical discovery with Jason and Ben30–60 minutes · what a solution looks like
Write: [email protected]

RENDR WEB · FORGE · PARTS · COMPLYQueensland-based · working across Australia · ABN 71 685 784 641