Most security conversations revolve around networks and antivirus, yet what an attacker is after usually sits inside an application: invoicing in Sage 200 or a3ERP, the CRM with every customer, the PrestaShop store with its orders and addresses, the portal where patients download their reports. And inside those applications the doors are often open in the most ordinary ways: every user set up as an administrator “so they stop asking for permissions”, the shop integration running under the managing director's account, a Redsys payment gateway key sitting in a config file inside a repository shared with the web agency. We review business applications from the inside: who can do what, which credentials they use to talk to each other and what gets checked before a new version goes live.
We work with off-the-shelf applications (ERP, CRM, online shops, clinic management software) as well as in-house builds. For in-house builds we coordinate with your developers or the agency that maintains them.
We review permissions inside the ERP, the CRM or Holded: who can change prices, cancel invoices, export the customer base or alter a supplier's IBAN. Profiles are defined by job and assigned from the directory where the application allows it.
Every automated link, such as shop to ERP, ERP to bank or CRM to mailing tool, gets its own service account with just the permissions it needs, rather than the director's login or that of whoever set it up.
We move API keys, database passwords and payment gateway credentials out of config files and repositories into a secrets manager such as Azure Key Vault or the platform's own vault, with regular rotation.
MFA and, where possible, single sign-on through Entra ID or Google for the PrestaShop back office, the CRM and supplier portals. One less password that can leak.
An inventory of libraries, plugins and third-party modules, with alerts on vulnerable versions. In PrestaShop and WooCommerce, abandoned modules are one of the most common ways in.
A record of who changed a price, cancelled an order or edited a supplier's bank details. It is the basis for spotting internal fraud or the familiar fake change-of-bank-account scam.
We do not halt development or operations. Changes to roles and credentials are made in batches, with the people who use each application on hand.
A list of business applications, their users, their integrations and where credentials are stored. There is usually one integration nobody remembered.
Over-privileged integration accounts and exposed keys come first: new accounts are created, keys rotated and old ones retired.
Profiles are redesigned with each department head and applied step by step, starting with finance and administration.
For in-house software, we add dependency and secret scanning to the release process together with your team or agency.
One of the commonest frauds against SMEs needs no malware at all, just a changed IBAN. If any ERP user can edit a supplier's bank details without approval or a record, the next payment can land in someone else's account. Separating who changes the details from who approves them takes an afternoon of configuration.
Yes, working with them. We agree with you what each role should be able to do, and either the reseller or Apply applies it, depending on who knows your version better. What matters is that decisions on permissions belong to your company and are written down.
No. Here we review configuration, permissions and credentials from the inside, with full access. A penetration test attacks the application from outside to find exploitable flaws; it belongs to our penetration testing service and makes sense before launching a new application or after a major change.
Partly, yes. The Verifactu regulation requires the integrity, traceability and immutability of invoicing records, which means controlling who can change them and leaving a trail of every change. We review those technical controls; adapting the software's functionality is for your developers or vendor.
Give them named accounts with MFA and only the permissions their work needs, not super-admin. And disable them when the job ends. It is one of the most frequent findings: agency logins still active years after the agency stopped working on the shop.
Tell us which ERP, CRM or online shop you use and how they connect to one another. We will reply with the checks we would run first.
Your request is with us
Expect an answer within one working day. A reported fault that has halted your team is handled first.
No match found. Try another spelling, or go with the closest provincial capital: every job is done remotely, so the location makes no difference to what we deliver anywhere in Spain.
