Cybersecurity services, from a free website security audit to an authorised penetration test.

The scan tells you how your front door looks from the street. Whether the hinges are the right way round, whether the number is on it, whether somebody left a window open on the ground floor. That is genuinely useful information and it is free, and for a lot of small sites it is most of what there is to say.

What it cannot tell you is whether the lock actually works. To find that out, somebody has to be allowed to walk up and try the handle, and then try the back door, and then check whether the key that opens the office also opens the safe. That is a different activity with a different legal footing, and it is what the rest of this page is about.

We are deliberate about the difference because the security industry is not. Plenty of suppliers sell an automated scan as a penetration test and hand over a colour-coded PDF that nobody acted on and nobody could have acted on. The report looks thorough, the invoice looks reasonable, and no attacker was inconvenienced.

So: the scan is free and it is the honest top of this page. If it comes back clean and you have no user accounts, no payments and nothing sensitive behind a login, you may be finished. If it comes back clean and you have all three, the interesting questions have not been asked yet.

Every line above came from a normal request. No form was submitted, no login was attempted, no payload was sent anywhere. That constraint is not modesty, it is the law, and the next section explains why.

Notice what the output does not say. It does not say you are secure, because it cannot know. A site can pass every passive check and still let one customer read another customer’s invoices, because that flaw lives behind a login, in code the scanner never sees, in a query that forgot to filter by account. The most expensive findings we have ever written up would all have been invisible to a scanner.

Probing somebody’s system without their permission is a crime. In the United Kingdom the Computer Misuse Act 1990 makes unauthorised access to computer material a criminal offence, and it is the access that is unauthorised, not the damage, that creates the offence. In the United States the exposure is federal under the Computer Fraud and Abuse Act and additionally under the computer crime statutes several states maintain of their own.

None of that turns on intent, and good intentions have not historically been much of a defence. It also does not turn on whether the target notices. A tool that quietly tries a hundred injection payloads against a form is doing the thing the statute describes, whoever is holding it and whatever the button was labelled.

So a scanner you can point at any domain has to be passive, or the people running it are committing an offence on behalf of every user who types a competitor’s name into it. Ours reads TLS and DNS, requests pages the way a browser does, and looks at what comes back. That is it. If a check would require sending something your server did not invite, the check is not in the tool.

Authorisation is what changes the picture, and it has to come from somebody who can actually give it: the owner of the domain and the system, in writing, with the scope and the window named. Where your hosting or cloud provider requires notice, that gets handled too. This is not legal advice, and if your situation is unusual you should take some, but the practical rule is simple. Nobody tests anything here until a document exists saying they may.

Reading the source is the highest-yield security work there is, and it is the least glamorous. A tester on the outside has to guess at the shape of your authorisation logic. A reviewer with the repository open can see it, including the three endpoints where somebody wrote the query without the tenant filter because they were in a hurry on a Friday.

We read for the classes of problem that actually cause breaches rather than producing a style report: authentication and session handling, authorisation checks at every boundary rather than only in the UI, input handling and output encoding, secrets in the repository or in the build, the dependency tree and what it pulls in transitively, and how errors and logs treat sensitive data on the way out.

A penetration test is somebody trying, on purpose and with your permission, to do the things your application is supposed to prevent. Log in as a customer who is not them. Read a record belonging to another account. Change a price on the way to checkout. Get a file to be executed instead of stored. Turn a low-privilege account into an administrator by way of three small steps that were each individually reasonable.

The finding that matters is almost never a single dramatic hole. It is a chain: an identifier that increments predictably, plus an endpoint that checks authentication but not ownership, plus an export feature that does not re-check either. None of the three is a critical finding on its own, which is exactly why a scanner ranks them low and an attacker does not.

We test against your real roles, because authorisation bugs only exist between roles. That means you provision us accounts at each privilege level before we start, and it means the test finds the class of problem that costs companies their customers rather than the class that costs them a header.

More companies are compromised through configuration than through code. A storage bucket that was public for one afternoon during a migration and stayed that way. A database reachable from the internet because the security group was widened for a contractor in 2022. A CI pipeline holding a key with permissions far beyond deployment. A role with a wildcard on it that nobody has dared narrow since.

The review is read-only and it goes account by account: identity and access management, network exposure, storage permissions, secret handling, logging and whether anybody would actually notice an incident, backup existence and, more to the point, whether a restore has ever been tested. Where your infrastructure is defined in code, we read the definitions as well as the live state, because the two diverge and the difference is usually where the problem lives.

The cheapest security work happens before anything is built. A threat model is a deliberately unglamorous exercise: draw the system, mark every boundary where data crosses from one trust level to another, and ask what somebody could do at each one if they wanted to. Two days of that at the start of a project routinely removes work that would have cost weeks to retrofit.

It also produces decisions rather than warnings. Where does the tenant identifier come from, and can a request influence it. What is the blast radius of the service account this component uses. Which actions are irreversible, and do they have a second pair of eyes. What does this system log, and would that log be a breach in itself if somebody exported it.

For teams building with us, this is folded into the audit week and the architecture that comes out of it. For teams building elsewhere, it is a standalone engagement: we model the system with your engineers in the room and leave you with the diagram, the boundary list and the decisions, whether or not we write any of the code.

MedArc is the case that makes the argument. The engagement was twelve weeks in 2022 and it was a rebuild, not a report, because the findings were architectural. The retest came back at zero critical findings. The cheaper version of that story is the one where the architecture was right in week one, and that version is available to anyone who has not started yet.

If you think something has already happened, the order of operations is different. First establish what is still reachable and close it. Then work out what was reached and when, from logs, before anybody starts rebuilding and destroys the evidence. Then rotate every credential that could plausibly have been exposed, which is usually a longer list than the first meeting suggests. Then remediate, then write it down.

We are not a retained incident response firm with an hour-one guarantee, and if you are mid-incident with regulatory deadlines running you may need one. What we do is the engineering half: find the route in, close it properly rather than cosmetically, rebuild what has to be rebuilt, and produce a written timeline your customers, insurer or regulator can be shown.

This is the part of the practice that is genuinely different, and the reason is unglamorous: we build these systems every week. Eazetech has AI products and agents in production, so the failure modes below are not read from a framework, they are the things we have had to design around in our own builds.

Prompt injection is the headline and the least interesting version of it is the direct one, where a user types instructions into a chat box. The version that actually causes damage is indirect: instructions arriving inside a document your system retrieved, a web page it fetched, a support ticket a stranger filed, a field in a record somebody else controls. The model has no reliable way to tell your instructions from theirs, so the defence cannot live in the prompt. It has to live in what the system is permitted to do afterwards.

Which is the real finding in most AI security work: permissions. An agent given a credential that can read every customer record, because that was the credential lying around, is one convincing paragraph away from being a data export tool. We review what each tool call can reach, whether irreversible actions require a human, whether retrieval is scoped per tenant, and whether model output is treated as untrusted input before it reaches a browser, a shell or a database.

The authorisation document is short and it is not a formality. It names the exact systems in scope by domain, IP range and application, the systems explicitly out of scope, the testing window, the accounts we will use, the techniques excluded, and the person on your side who can call a halt. Both sides sign it and both sides keep a copy.

It also protects you. A signed scope is what stops a test drifting into a system somebody else owns, which is a real risk when a shared load balancer or a third-party subdomain is involved. If your application depends on a service you do not control, testing it needs their permission too, not yours, and we will say so rather than proceed and hope.

The last two items are the ones most reports omit and the ones that make a report usable a year later. A finding list without a coverage statement cannot be read as reassurance about anything, because there is no way to tell whether an area was clean or simply never opened.

Severity is argued rather than asserted. A stored cross-site scripting flaw in an admin console used by four people who are already trusted is not the same risk as the same bug on a page every customer visits, and a tool that scores both the same is not helping you decide what to do on Monday. Where we disagree with the scanner we say why.

Anything critical does not wait for the report. It goes to your named contact the day it is found, with enough detail to fix it, because a two-week gap between discovery and disclosure is two weeks you did not need to spend exposed.

MedArc came to us in 2022 with a healthcare application and a set of findings that were architectural rather than cosmetic. The engagement ran twelve weeks and it was a rebuild. At retest it came back at zero critical findings, and that is the number on this page because a retest result is the only security number worth quoting.

Here is what it does not mean. It does not mean MedArc is unbreakable, or that they were finished, or that the same result would hold two years later without further work. It means that on the agreed scope, at the date of the retest, no critical finding remained open. That is a precise claim, and precision is the whole point of a security number.

So every test we do includes a retest inside ninety days. We re-run each finding and mark it fixed, partially fixed or unchanged. Partially fixed is a real category and it comes up more than teams expect: the endpoint that was reported got a check added, and the three siblings that share the same handler did not.

You get a short retest letter stating the scope, the dates and the status of every finding. It is the document that satisfies a customer’s security questionnaire, an insurer, or an auditor asking what you did about last year’s report. A test without a retest leaves you with a list of problems and no evidence you addressed them, which is the worse half of the transaction.

Nobody can make you secure. Not us, not a larger firm, not a tool with a dashboard. A system that people use and change every week has a moving attack surface, and any statement about it is true on a date and about a scope, not forever and not in general. A supplier who tells you otherwise is either inexperienced or counting on you not to notice.

We also will not tell you the internet is a dangerous place and hope you buy something. You know the risk exists. What you actually need is a specific list of what works against you today, what each item would cost you if used, what to do about it, and evidence afterwards that you did it.

So the claims on this page are deliberately narrow. The free scan checks what is visible from outside and says so. A review is one person’s informed opinion in one week. A test finds what a competent person could do within an agreed scope and an agreed window, which is not the same as what an unlimited attacker could do given a year. MedArc’s zero critical findings is a retest result on a defined scope in 2022.

Every one of those is a smaller claim than the industry norm, and each of them is one we can stand behind in front of your auditor. That trade has been worth making for ten years and we are not going to stop now.