For businesses whose systems are connected by credentials nobody tracks

Integration Security: The Standing Keys to Your Business Data

An integration is a permanent set of credentials, usually with broad permissions, allowed to read and write your customer, order and financial data without a human present. In most Australian businesses those credentials were created during a project, stored in a spreadsheet or an email, granted full administrator rights because it was quicker, and have not been reviewed since.

This is not a theoretical exposure. It is how a departed contractor still has access, how a marketing tool ends up holding a full customer export, and how a breach in one vendor becomes a breach in your systems. The good news is that the fixes are ordinary engineering and administration rather than expensive security products. This page sets out what to do.

Book a Security Review (03) 9003 0111

Realistic ROI

One identity

Per integration, never a staff login

So a resignation is a handover rather than an outage and an access review is possible

Least privilege

Scopes limited to what the flow needs

Read only where nothing is written, and no admin rights by default

Rotate on a schedule

Not only after an incident

Rotation you have practised is rotation you can perform in an emergency

Log less

Keep what supports diagnosis, mask the rest

Logs are a collection of personal information and are governed accordingly

Four Principles That Do Most of the Work

Integration security is unglamorous and largely consists of four habits applied consistently.

Integrations get their own identity

Connections authorised with a staff member’s login inherit that person’s permissions, break when they change their password, and vanish when they leave. Worse, the audit trail shows a person doing things at three in the morning, which makes any investigation harder. Every integration should have its own named service identity, owned by a role rather than an individual, with its purpose documented so nobody has to guess what will break if it is disabled.

Permissions are scoped to the job

Most integrations are granted administrator rights because it was the fastest way to get past a permissions error during the build, and nobody returns to narrow them afterwards. Grant only the specific permissions the flow needs, read only where the flow only reads, and restrict to the objects it actually touches. When the connected vendor is compromised, the scope of your exposure is exactly the scope you granted.

Secrets live in a secret store

Credentials in configuration files, spreadsheets, chat threads, ticket comments and email are the normal state of affairs and the most common way access leaks. Keys belong in a managed secret store with controlled access and an access log, injected at runtime rather than copied around, and they should be rotatable without someone editing code or hunting through documents to find every copy.

Only what is needed crosses the wire

Integrations routinely move far more personal information than the task requires, because sending the whole record was easier than choosing fields. Every extra field is stored, logged and replicated somewhere else, and under the Australian Privacy Principles it is information you now have to protect, disclose about and eventually delete. Send the fields the destination genuinely needs and no more.

The Practical Controls

Six controls that between them prevent most integration security incidents in small and mid sized businesses.

Know what exists

Credential inventory

A register of every integration credential: which system, which identity, what scopes, who owns it, when it was created, when it expires and what depends on it. Almost no business has this, and building it is invariably where the first surprises appear, usually in the form of active credentials belonging to former staff, trial tools and agencies you no longer work with.

Practised change

Rotation without outage

A defined process for replacing a credential: create the new one, deploy it, verify the flows, revoke the old one. Practised on a schedule so it is routine, because the day you need to rotate urgently is the day a vendor has had a breach and everyone is already under pressure. Rotation that has never been performed is a plan, not a control.

Trusted input

Verify what arrives

Incoming webhooks are verified against the vendor signature and rejected if unsigned, altered or stale. File transfers use key based authentication with known hosts. Every payload from outside is treated as untrusted input and validated before it touches a business system, because an endpoint that accepts anything will eventually be sent something.

Useful, not hoarded

Minimise and mask logs

Record level logging is essential for support and is also a store of personal information. Keep the identifiers and status needed to diagnose and replay, mask payment details and sensitive fields, set a retention period and enforce it automatically, and restrict who can read raw payloads. Support staff need to trace a record, not to browse your customer base.

Nothing lingers

Access reviews and offboarding

A periodic review of who and what has access, tied into the process for staff and contractor departures and for ending a vendor relationship. Integration credentials are almost never included in offboarding checklists, which is why access outlives relationships by years. Add them to the checklist and the problem largely solves itself.

Know the steps

Incident readiness

A short plan for what happens if a credential leaks or a connected vendor reports a breach: which credentials to revoke, what data that connection could reach, how to determine what was accessed, who decides, and the Notifiable Data Breaches obligations that may follow. Written in advance, because the first hour of an incident is not the time to be working out which systems a key opens.

Situations Worth Being Ready For

Task	Traditional	Done Securely	Notes
Developer or agency leaves	Access quietly persists	Credentials revoked in offboarding	Only possible if the credential register exists and integrations do not use personal logins.
Connected vendor reports a breach	Scope unknown, panic	Scope known from the register	The permissions you granted are the exposure. Least privilege turns a crisis into a task.
Staff member changes password	Integration stops overnight	Unaffected, it has its own identity	The most common accidental outage in small business integrations.
Marketing tool requests a customer export	Full database shared	Only the fields required	Every extra field becomes something to protect, disclose about and eventually delete.
Webhook address becomes known	Anything posted is accepted	Signature verified, rest rejected	Fabricated orders or cancellations posted into your systems is a real and cheap attack.
Support needs to trace a record	Full payload access for everyone	Masked view, elevated on request	Diagnosis rarely requires reading unmasked personal information.
Testing against real data	Production copy on a laptop	Masked subset in a controlled space	Realistic testing is achievable without distributing your customer list.
Key rotation needed urgently	Nobody knows where it is used	Register plus practised rotation	Rotation is only a control if it has been performed when nothing was on fire.

Where Integration Security Fails in Practice

The shared administrator login

One powerful account, known to several people and used by several tools, is the most common arrangement and the hardest to unwind later. It defeats audit trails, cannot be rotated without breaking unknown dependencies, and cannot be revoked when one relationship ends. Replace it with per integration identities as part of the next piece of work rather than as a project of its own, starting with the systems holding the most sensitive data.

Credentials copied into places that are never cleaned

Keys pasted into tickets, chat threads, email, documentation and configuration files persist long after the credential is rotated in the place you remembered. Move secrets into a managed store with access logging, reference them rather than copying them, and when you rotate, treat every historical copy as compromised. Searching your own systems for stray credentials is an uncomfortable and worthwhile afternoon.

Privacy obligations treated as a policy document

Moving personal information between systems engages the Privacy Act 1988 and the Australian Privacy Principles in concrete ways: only using and disclosing information for the purpose it was collected, taking reasonable steps before disclosing it to overseas recipients, protecting it with reasonable security, and being able to correct or delete it across every connected system rather than only the one the customer contacted. These are design requirements, not paperwork, and they are much cheaper to build in than to retrofit.

No idea where the data physically sits

Integration platforms, logging services and connected applications store data somewhere, and that somewhere is often overseas. Knowing which country each component stores data in matters for your privacy disclosures, for customer questions, and sometimes for contractual or sector obligations. Ask each vendor directly, record the answer alongside the credential register, and revisit it when they change their infrastructure.

No plan for the breach that involves someone else

Under the Notifiable Data Breaches scheme, an eligible data breach involving personal information you hold can require notification to the Office of the Australian Information Commissioner and to affected individuals. A breach at a connected vendor can put you in that position through no fault of your own. Know which connection could reach which data, keep enough access logging to assess what happened, and agree in advance who makes the assessment and the call.

Security review treated as a one off

Scopes widen over time as flows are extended, new tools are connected during projects, and staff who understood the arrangement move on. An annual review of the credential register, the granted scopes, the log retention settings and the vendor list catches this drift while it is still small. Put it in the calendar with an owner, alongside the other annual obligations the business already manages.

How Yes AI Handles Integration Security

We build the credential register first

Every connection, identity, scope, owner and expiry, including the ones nobody remembered. It is usually the most immediately useful document produced by any integration engagement, and you keep it whether or not we do further work.

Least privilege as the default

Service identities with scopes limited to the flow, read only where nothing is written, secrets in a managed store, and rotation designed in from the start rather than discovered to be impossible during an incident.

Managed infrastructure we operate

Flows run on a managed cloud automation layer with signature verification, masked logging, enforced retention and controlled access to payloads. We can tell you where each component stores data and how long it keeps it.

A handover that survives us

Documentation, credential ownership and access arrangements structured so you can hand the work to another provider or take it in house without a hostage situation. Anyone unwilling to agree to that is telling you something.

From Unknown Access to a Controlled Set

Five steps. The register and the immediate risks usually take under two weeks.

Inventory every credential and connection

What exists, what it can reach, who owns it, when it expires and what depends on it. Expect to find active access belonging to former staff, trials and past providers.

Close the obvious exposures

Revoke what is unused, replace personal logins with service identities, move secrets out of documents and chat into a managed store, and narrow the widest scopes first.

Harden what data moves

Reduce payloads to the fields actually needed, mask sensitive values in logs, set and enforce retention, and verify signatures on everything arriving from outside.

Make rotation and review routine

A practised rotation procedure, a scheduled access review, integration credentials added to the offboarding checklist, and vendor data locations recorded alongside the register.

Prepare for the incident

A short plan covering revocation, scope assessment, logging sufficient to determine what was reached, decision rights, and the notification obligations that may apply.

FAQ

Why should an integration have its own login?

Because a connection authorised with a staff member’s account inherits their permissions, breaks when they change their password, disappears when they leave, and makes the audit trail meaningless by attributing automated activity to a person. A dedicated service identity per integration can be scoped narrowly, owned by a role, reviewed, rotated and revoked independently, and it makes questions like what would break if we disabled this answerable rather than alarming.

What does least privilege mean in practice?

It means granting the specific permissions a flow needs and nothing else: read only access where the integration only reads, access to orders but not to staff records if orders are all it touches, and no administrator rights unless a specific task genuinely requires them. The test is simple. If a connected vendor were compromised tomorrow, what could an attacker do with the access you granted them? Whatever the answer is, that is your exposure, and it is entirely within your control.

How often should we rotate integration credentials?

On a schedule you can actually keep, commonly annually for routine connections and more often for anything touching payments or sensitive personal information, plus immediately whenever a person with access leaves or a vendor reports an incident. The frequency matters less than the fact that rotation has been performed at least once outside an emergency, because a procedure nobody has exercised will not work well on the day it is genuinely needed.

What are our obligations when integrations move personal information?

Broadly, under the Privacy Act 1988 and the Australian Privacy Principles you must use and disclose personal information only for purposes consistent with why it was collected, take reasonable steps to protect it, take reasonable steps before disclosing it to overseas recipients, and be able to access, correct or delete it on request. In integration terms that means minimising the fields you move, knowing where each connected system stores data, restricting who can read payloads and logs, and being able to honour a deletion request across every system rather than one. This is general information rather than legal advice.

What should we do if a connected vendor has a breach?

Revoke or rotate the credentials for that connection immediately, establish from your register what data that connection could reach, use your logs to assess what was actually accessed, and involve whoever makes privacy decisions in your business. If personal information you hold is likely to have been compromised in a way that could cause serious harm, the Notifiable Data Breaches scheme may require notification to the regulator and to affected individuals. Preparing the register and the logging in advance is what makes that assessment possible rather than speculative.

Is it safe to test integrations with real customer data?

It is common and it is worth avoiding. Copies of production data spread onto laptops, test environments and vendor sandboxes with weaker controls, and they rarely get deleted. The workable middle ground is a masked subset that keeps the awkward shapes of real data, such as long names, apostrophes, missing fields and historical oddities, without carrying identifiable personal information. Where a genuine production test is unavoidable, scope it tightly, log it, and clean up deliberately afterwards.

Do we need a security review if our integrations already work?

Working and safe are different questions. A review is worth doing when nobody can produce a list of what has access to your systems, when integrations were built by people who have moved on, when you are connecting anything holding customer or financial data, or when a client or insurer starts asking. In most cases the findings are ordinary and fixable: over broad permissions, credentials in documents, logs kept forever, and access belonging to relationships that ended years ago.

Find Out What Actually Has Access

Book a call. We build the register of every credential and connection, show you the exposures worth closing first, and give you a priced plan. The register is yours either way.