A franchise marketing platform holds the credentials to your ad accounts and can spend real money on your behalf. That is a bigger ask than most software makes, so here is what protects it, in plain words.
Each of these is described further down. If your security team wants the long version with file names and test counts, ask for the supplier pack.
Most software only holds data. A platform that pushes campaigns to Meta and Google can also spend, so the question is not only who could read your data, but how much of the network's money they could burn first. Amplaro answers that with limits written into the code: per campaign, per client per day, per client per month, across the platform per day, plus a maximum cost per click and a longest flight. Those numbers hold even if nobody configures anything.
At the order, again when the payload is built, and again inside the only three functions that can push spend to an ad platform.
Head office can pull their own limits tighter. Every stored value is clamped on the way in, so nothing lands above the built-in ceiling.
A hard limit only moves with a change to our hosting environment and a release. A stolen session must not unlock more money than shipping code does.
If the check cannot complete, the push is refused rather than allowed through, and the refusal is logged before the error is raised.
A freeze stops every new push to Meta and Google while the rest of the platform keeps working.
The live campaign list is pulled from both ad platforms and compared with our own records. Anything running that we did not create is flagged.
Two things this cannot cover, because they sit outside the platform: money spent by editing a campaign directly in Ads Manager, and money already spent. A spend cap on the ad account itself is worth setting.
Checkout is a full redirect to the payment provider's own hosted page. Not an embedded form, not hosted fields, not an iframe, and no payment script anywhere in the Amplaro front end, which we check rather than assume. The card number only ever exists on the provider's domain.
We store a session reference, a payment reference and an amount. Coming back from paying, the platform re-reads the payment server to server, so a faked return address cannot mark an order paid. The merchant account is your own and Amplaro never holds anybody's funds. What the money pays for is on pricing.
Two factor is mandatory for platform admins, not offered. The account cannot be used without an enrolled authenticator, and ten single use recovery codes are issued once and stored hashed.
For your own team there is Microsoft Entra single sign-on, per organisation. Run it alongside passwords first, then make it the only way in, so your conditional access and MFA policy decides who gets a session. The classic Entra trap is the client secret expiring and locking out the people who could fix it, so the platform tracks that date, warns on an escalating schedule, and suspends the requirement rather than locking your team out.
Attempts are counted against both the address and the network address, with a short lockout after repeated failures. The counters live in the database, so a release does not hand an attacker a clean slate, and the refusal message is the same whether or not the account exists.
Sessions can be revoked for one person or for everyone at once, both needing a written reason and both logged. Changing a password signs that person out everywhere. The cookie is signed, http only, and HTTPS only in production.
There are two roles, head office and franchise partner, plus a platform admin flag that no screen, form, import or endpoint can grant. A partner sees their own stores and nothing else. What head office can and cannot do is on for head office, and the rules a partner cannot get around are on brand control.
Ad platform tokens, the payment key, the single sign-on client secret and two factor seeds are encrypted in the database column with AES-256-GCM. The key is an environment variable. Not in the database, not in the repository, not in any backup, so a copy of the database on its own does not open your ad accounts.
Production refuses to start without that key. On every boot the server decrypts a known value to prove the key is right, and if it is not, the new version never serves and the previous one keeps running. Keys can be rotated: the tool dry runs first, stops if a single value cannot be read, and rewrites everything in one transaction.
Passwords are bcrypt hashes, never recoverable, only resettable. Everything travels over HTTPS with strict transport security. Every page carries a content security policy built on the same idea as the rest of this page, everything from our own address and nothing else, so no external script can load and injected code cannot send anything out. Frames are refused, content type sniffing is off, and camera, microphone, geolocation and payment are turned off at the browser level.
Recovery point objective 24 hours, recovery time objective 4 hours. A restore of a database this size takes minutes, so most of those 4 hours is allowance for noticing, deciding and provisioning.
Each backup is a full dump of every row, written with a checksum and a row count per table, so a half finished file cannot be mistaken for a good one. It is encrypted under a separate key before it leaves the server, copied off site to storage held by a different company from the host, then asked for again and checked.
Restores are tested rather than assumed. The test fingerprints every row, restores into a throwaway target and compares, and the date sits in the console. A full drill has been run end to end: restored into an empty database, the application booted against it, sign-in working, and new records written afterwards getting clean identifiers.
Around 1,500 automated checks run across twelve parts of the platform before anything ships. That proves the code, not the live platform, so a second sweep runs every night against production itself: can a partner order right now, do Meta and Google still accept our credentials, does the payment provider answer, is there a recent backup, is the audit log still being written.
The report goes out on a good night too. A report that only arrives when something is wrong looks exactly like a report that has stopped working, and you find out which one you had on the night you needed it. Unhandled errors alert within seconds, and alerts about the platform come to us, never to a client.
One honest note. The check that notices a sweep has gone stale runs in the same process as the sweep, so it cannot notice that process being dead. An external uptime check is on the list and is not in place yet.
Yes, technically, and we would rather write it here than have it surface halfway through your review. There is a platform admin account that can act inside an organisation, which is what makes support possible at all. Every use of it is written into that organisation's own audit log, so it is visible to you and not only to us. There is exactly one, because nothing in the product can grant that flag to anybody.
One franchise brand cannot reach another one's data anywhere in Amplaro. Worth knowing for a review: that separation is enforced in application code rather than at the database level. The platform-wide health screen is the one place an admin can see across organisations, which is why it is admin only and defaults to the organisation you are signed in to.
The audit log records who did what and when, with a name attached, across campaign packages, launches, payments, user changes, settings and anything an admin does inside your organisation. It is kept for two years, because keeping it forever is not a policy, it is the absence of one. What else head office keeps hold of is on for head office, and what is reported back per store is on reporting.
A short list on purpose. Amplaro runs as one application with nine runtime dependencies, no shell, no SSH and no admin port exposed. These are the other companies involved, and what each of them can actually see.
| Who | What they do | What they can see |
|---|---|---|
| Railway | Runs the application and the managed database | Everything, as the host |
| Cloudflare R2 | Holds the off-site backup copies | Encrypted files. The key is not held there |
| Stripe | Takes card payments on their own hosted page | The card and the payment, nothing else |
| Meta and Google | The ad platforms campaigns are pushed to | Your own ad accounts, which you already own |
| Cloudprinter | Prints and delivers local print material | The artwork and delivery address for that order |
| Resend | Sends notification and alert email | The address and contents of those emails |
| OpenStreetMap and Carto | Map tiles behind the delivery area editor | Which map tiles a browser asked for |
Swipe the table sideways to see the rest.
On residency: the application and its database run in a hosted United States region today. Moving to an Australian or European region is a move rather than a rewrite, but it needs lead time, so raise it early if it is a hard requirement for your brand. How data is handled is on privacy, the commercial side on terms.
Email hello@amplaro.com.au with "security" in the subject line and we will confirm we have it. There is no paid bug bounty. What we ask is the usual: no testing against real client data, nothing that degrades the service for a partner who is trying to work, and a reasonable window to fix it before publishing.
Running a vendor security review and want the long version? Ask us for the supplier pack. It has the architecture and data flow diagrams, the control descriptions with the file names behind them, the test counts, and a written list of what is not built yet with dates against it.
No, and we are not going to imply otherwise. No ISO 27001, no SOC 2 report, no third party penetration test. What a review gets instead is a written description of every control, an architecture and data flow diagram generated from the repository rather than drawn by hand, and a direct answer on anything we cannot evidence. If certification is a hard procurement requirement, raise it in the first conversation rather than the fifth.
In a hosted United States region today, with encrypted off-site backups held by a separate storage provider. Australian or European residency is a move rather than a rewrite, but it needs lead time, so raise it before a questionnaire asks.
Yes, technically. There is one platform admin account that can act inside an organisation, which is what makes support possible at all. Every use of it lands in that organisation's own audit log, so it is visible to you and not only to us, and nothing in the product can grant that flag to anybody else.
A bounded amount, and that is the point. The limits are written into the code, they fail closed, they are checked at three points on the way to Meta or Google, and an override can only ever lower them. Raising a ceiling needs a deploy, so a stolen session, a stolen API key or a copied database cannot lift it.
No. Checkout is a full redirect to the payment provider's own hosted page and there is no payment script in the Amplaro front end, so no card number and no stored card sits in our database. Our reading is that this is the simplest PCI category, which is for a qualified assessor to confirm rather than for us to rule on.
Yes, Microsoft Entra ID, per organisation with your own app registration. It can run alongside passwords first and then become the only way in, so your own conditional access and MFA policy decides who gets a session. Google Workspace and Okta are not built, and there is no SCIM, so accounts are created in Amplaro rather than provisioned from your directory.
Daily, with a recovery point objective of 24 hours and a recovery time objective of 4 hours, and tighter is a single setting if a client needs it. They are checksummed, encrypted under a separate key and held off site by a different company from the host. Restores are tested rather than assumed and the last test date is in the console.
A partner can only order campaigns for their own stores inside the rules head office set, so the exposure is a campaign order, not access to the network. Sign-in attempts are throttled, sessions can be revoked for one person or for everyone at once, spend limits still apply, and one switch stops every new push to the ad platforms.
Two years by default. It records who did what and when, with a name attached, across campaign packages, launches, payments, user changes, settings and anything a platform admin does inside your organisation.
The controls above exist because of how the platform is shaped. Eg: partners can only order what head office already approved, so there is nothing to review at launch. See how it works.
Control of the brand, the budgets and the reporting, without becoming the bottleneck for every local ad.
How head office can build a quarter of campaign packages with an LLM, as drafts, with every action logged.
What to compare when you are looking at franchise marketing platforms, and the questions worth asking early.
Half an hour with the platform, and straight answers on the parts your review will ask about.
Book a demo