(Security) · built · reviewed · watched

Secure, then kept secure.

Name: neo optic
Address: Norwich, Norfolk, GB
Telephone: 0800 688 9010
Price range: ££

Any competent team can make a site secure on launch day. Keeping it that way for the next five years is a different promise - and it is the one almost nobody puts in writing.

Ask about your setup + independent review before release + weekly advisory watch + we apply the fix

Most security conversations are about the build. The harder question arrives eighteen months later.

On the day a critical flaw is announced in something your site depends on - the framework, the database, a library nobody has thought about since launch - three things decide what happens next. Who applies the fix. How quickly. And how you would know it had been done. For a great many websites the honest answer to all three is nobody, because it was never agreed with anyone. That gap is what this page is about.

(How it works)

Three things that have to be true.

A small, known surface

No plugin marketplace, no page builders, no theme pulled from a directory. We own and control the application code and keep a deliberately small set of dependencies we can name. Every piece of third-party code on your site is there because we chose it, not because a template shipped with it.

Reviewed by someone who did not write it

Nothing leaves us until it has been through an independent adversarial review. The person who built it is never the only person who checked it. Findings are documented, remediated and re-tested, and that evidence comes with the handover rather than living in someone's head.

Watched every week after launch

Every Monday we review the week's advisories across the .NET, SQL Server, Windows Server, IIS and dependency stack, plus vulnerabilities being actively exploited in the wild. Each report says what is affected, whether it touches your site, how urgent it is, and what we are doing about it.

What is in the build itself.

Forgery protection as standardEvery action that changes something - a form, a save, a delete - carries a token proving the request came from your site and not from somewhere else pretending to be you.

Locked by defaultSign-in is required across an admin area by a single rule, not remembered page by page. The handful of pages that are deliberately public each re-check who is asking. Nothing is protected only because somebody remembered to protect it.

Text stays textAnything typed into the system is rendered as words, never as instructions. That closes the most common way a website gets turned against its own visitors.

Queries that cannot be rewrittenData access is parameterised throughout - no database query is ever assembled by gluing strings together, which is what makes injection attacks possible in the first place.

Uploads held under controlFiles are validated on arrival and stored where the platform decides, not where a request asks them to go.

Rate limits and quiet trapsPublic forms carry per-address limits, a hidden field no human ever fills in, and a minimum time on page - so automated abuse stops before it reaches you.

Least privilege everywhereThe account your site uses to reach its database can do what the site needs and nothing more. Credentials live in server configuration, never in the code.

None of this is exotic. All of it is the sort of thing that gets skipped when a site is assembled at speed from parts nobody in the room wrote.

(After launch)

The part that runs every week.

Security Watch, in plain terms

Software you depend on has flaws found in it constantly - that is normal, and it is true of every platform on earth including ours. What separates a maintained site from an exposed one is whether anybody is reading those announcements on your behalf. Every Monday we do exactly that, across the whole stack your site sits on. Most weeks the honest answer is that nothing affects you, and we say so. When something does, you hear what it is, how urgent it is, and what we are doing - usually before you have heard of it anywhere else.

(01)Advisories are read, not assumed

An advisory saying a component is vulnerable does not automatically mean your site is. The work is deciding whether the vulnerable path is one your site actually uses, and how exposed it is if so. That assessment is the job; the alert is just the trigger.

(02)Urgent things move immediately

Where something is being actively exploited, the fix is applied and you are told - not queued behind a monthly release. The window between a flaw becoming public and being used against real sites is now measured in hours rather than weeks.

(03)Fixes are tested like features

A patch or a framework upgrade goes through the same independent review and regression pass as new work. Nothing is assumed safe simply because a vendor published it.

What we do not claim.

Nobody is unhackable, and anyone saying otherwise is selling

We are not claiming our platform cannot have a vulnerability. Any non-trivial software can, ours included. What we claim is narrower and more useful: a smaller surface, a dependency list we can actually name, a review by someone other than the author, and a named owner for the fix. We are also not claiming that being less widely deployed is a security feature - it makes a platform a less attractive target for industrial-scale scanning, which is a real practical difference, but it is a consequence of scale rather than a control anyone designed. Anybody leaning on that as their main argument is leaning on nothing.

(Worth asking anyone, including us)

Four questions for any supplier.

Who applies the patch, and how fast?Ask for a name and a timescale. If the answer is that you do, that can be perfectly fine - but you should know it before you sign, not on the morning it matters.

Who checked the work?If the only person who reviewed the code is the person who wrote it, the review is worth very little. Ask who challenged it, and ask to see what they found.

How much inherited code is in there?Every plugin is somebody else's software running with full access to your database. You inherit the security practice of every author you install - and whoever takes the plugin over next year.

What happens if something gets in?Patching closes a door. It does not evict anyone already inside. Ask what the response looks like, who gets called, and how you would find out at all.

A fair answer beats a confident one

We would rather you asked these of every agency on your shortlist, ourselves included. If a supplier cannot answer them, that is worth knowing before you sign rather than afterwards. There is a longer worked example of exactly this going wrong on our platform page - a real invoice, sent to a real client, for a flaw in a plugin their agency chose. And if you run WordPress, our post on whether your site is safe gives you the free checks first, with no pitch attached. Ask us anything here.