You want an audit, but the thought of giving an outside specialist access to your live PrestaShop store makes you hesitate, and it should. Your shop holds customer records, order history, payment configuration, and the credentials that run your business. Handing keys to a stranger is a real risk, and being cautious about it is not paranoia; it is good operational hygiene. The good news is that a competent audit almost never needs the deep access people fear. This post explains exactly what different audits actually require, how to grant access safely to any auditor, what a trustworthy one will commit to in writing, the GDPR rules that apply to EU stores, and the warning signs that should make you walk away.
What access does an audit actually need?
The instinctive assumption, "they'll need my admin login", is wrong for most audits. The level of access depends entirely on what is being examined, and the spread is wider than people expect.
Audits that need nothing but your URL
The majority of common audits run entirely from the outside, against your public website, with no login at all. A SEO audit reads what Google reads: your rendered HTML, robots directives, sitemaps, canonical tags, structured data, and internal linking. A performance review measures real page loads, asset delivery, caching headers, and Core Web Vitals from the browser. A theme or hosting review can assess most of what matters, HTTPS and TLS configuration, server response, redirect chains, exposed paths, without ever signing in. This is the "outside-in" approach, and it is how we begin every engagement on our expert services hub. You enter your store URL on the service page, a read-only readiness check runs (it confirms HTTPS/TLS and detects PrestaShop, changing nothing), and only then is the audit ordered, the domain simply travels with the order.
Audits that may need read-only login access
Some deeper work does benefit from a look inside the back office, for example a configuration review, a module conflict diagnosis, or parts of a security audit that inspect installed modules, permissions, and settings. Even here, the auditor needs to read, not change. A read-only employee account is enough to see the catalogue structure, module list, and configuration without the ability to edit anything. And critically: no audit needs a copy of your customer or order database. None.
The safe way to grant access to any auditor
This advice applies to us and to every other auditor you might hire. Treat it as a checklist regardless of who you engage.
- Never share your own login or password. Your personal admin account is yours alone. Sharing it removes any audit trail, exposes everything you can do, and cannot be cleanly revoked. There is never a good reason to do it.
- Create a temporary, dedicated employee account. In PrestaShop, go to
Advanced Parameters > Teamand add a new employee for the auditor with its own email and password. This gives you a clean, named account you can switch off the moment work is done. - Apply least privilege. Use a permission profile scoped to read/view rights only. PrestaShop's permission system lets you grant "View" without "Add", "Edit", or "Delete". Withhold access to the customer and order sections entirely unless a specific, agreed check genuinely requires it.
- Time-box it. Grant access for the audit window only. Note the date you expect the work to finish, and plan to revoke on that day.
- Delegate, don't hand over, for third-party tools. For Google Search Console or Analytics, add the auditor as a delegated user with read access through the platform's own sharing. Never give them your Google password. The same applies to your hosting panel: a scoped sub-account beats your master credentials.
- Revoke when done. The instant the audit is delivered, disable or delete the temporary account and remove any delegated access. A trustworthy auditor will remind you to do this; do it anyway, on your own initiative.
- Prefer outside-in. If an audit can be done from the public URL, let it be. The least access that still gets the job done is always the right amount.
What a trustworthy auditor commits to
How an auditor handles access tells you a great deal about how they will handle your data. These are the commitments we make in writing, and the standard you should expect from anyone you hire.
- Read-only by default. An audit is a diagnosis. We change nothing without a separate, written, agreed scope. Looking is not the same as touching, and we keep the two strictly apart.
- We don't take your database. We never need, and never request, a copy of your customer or order data. If a specific check requires database access, it is read-only, and we never extract personal data.
- Nothing retained after delivery. Once the audit is delivered, access is gone and we hold nothing, unless you explicitly ask us to keep a backup for you.
- Your store is not our marketing. We never use your shop as a case study, portfolio piece, or example, even anonymised, without your written agreement. If you are happy to be featured, we thank you with a discount, but that is your choice, never a default.
- NDA or DPA on request. If you need a signed non-disclosure or data processing agreement before we begin, ask. We will sign one.
GDPR specifics for EU stores
If you run a store in the EU, the relationship is not just a matter of trust, it is regulated. When an auditor touches personal data on your behalf, you are the data controller and the auditor acts as a data processor. That distinction carries obligations on both sides.
Your responsibilities as the controller: grant only the access strictly necessary, keep a record of what you shared and with whom, and put a data processing agreement (DPA) in place where personal data is involved. A reputable processor will act only on your documented instructions, audit-only, with no transfer to third parties, no reuse for other purposes, no use as training data, and no marketing. We are EU-based, in Tychy, Poland, and when an audit touches personal data we act strictly as a processor on your instructions. A DPA is available on request. Being able to point to where the data sits, and under whose jurisdiction, is itself part of the answer.
Red flags: when to walk away
Trust is earned by behaviour, and a few requests should end the conversation immediately:
- They demand full admin access up front for an audit that hasn't even started. A diagnosis does not require the ability to change everything.
- They won't sign an NDA or DPA. A professional handling your data should have no problem committing to confidentiality in writing.
- They ask for your customer export, a dump of orders, emails, or personal data. No legitimate SEO, performance, theme, or security audit needs your customer list.
- They want your personal login rather than a dedicated account, or push back when you insist on read-only, time-boxed access.
Any one of these is a reason to choose someone else.
Start with just your URL
The safest audit is the one that never asks you to lower your guard. We have written our full position on access and data handling so you can read it before you commit anything. See our store audit readiness policy, which sets out, in plain language, exactly what we do and don't do with access to your shop. And because most of our work runs outside-in, you can begin a security audit or browse the full range of readiness and audit services with nothing more than your store URL, no login, no database, no leap of faith required.
Frequently asked questions
Will you ever need my admin password?
No. There is never a good reason to share your personal admin login with anyone. It removes the audit trail, exposes everything you can do, and can't be cleanly revoked. If a check genuinely needs a look inside the back office, the right answer is a temporary, named, read-only employee account that you create and switch off when the work is done. Most of our audits don't even need that much; they run from your public URL.
How do I make a read-only account that can't change anything?
In PrestaShop, go to Advanced Parameters > Team, create a new Profile (for example "Auditor"), and in Permissions tick only the View column for the sections being reviewed. Leave Add, Edit, and Delete unticked. Then add an employee assigned to that profile, with its own email and password. Withhold the Customers and Orders sections entirely unless a specific, agreed check needs them. When the audit is delivered, disable or delete that employee.
What if an auditor genuinely needs to look at customer or order data?
It's rare, and it should be the exception, scoped and agreed in writing before it happens, never the default ask. When it's justified, access stays read-only, limited to the specific check, and no personal data is extracted or copied off your store. For EU stores this is exactly where a DPA belongs: you're the controller, the auditor is the processor acting only on your documented instructions. If someone wants a bulk export of your customer list "to be thorough," that's a red flag, not a requirement.
Can I revoke access part-way through if I change my mind?
Yes, that's the whole point of a dedicated, time-boxed account. Because it's a separate employee profile and not your own login, you can disable or delete it at any moment without disrupting your own access or anyone else's. The same applies to delegated Search Console or hosting-panel access: you remove the delegation through the platform's own sharing controls whenever you choose. Retaining that off-switch is exactly why you never share your personal credentials.
You're outside my country. Is my data safe under GDPR?
We're EU-based, in Tychy, Poland, so for EU stores the data stays within the EU and under EU jurisdiction. When an audit touches personal data we act strictly as a processor on your documented instructions: audit-only, no transfer to third parties, no reuse, no training data, no marketing. A DPA is available on request, and being able to point to where the data sits and under whose law is part of what makes the relationship accountable. For most audits the question is moot anyway, because we never take your data in the first place.