Okay, But Actually… Your Six-Figure Business Does Not Need Enterprise Cosplay

I keep seeing the same warning whenever a smaller business considers custom software.

Large companies have dedicated IT departments, security specialists and compliance teams, so the argument goes that owning a custom platform means you will need all of that too.

That conclusion is usually reached before anyone knows what is being built.

A business might want a client portal, an internal dashboard, a quoting tool or one system to replace six spreadsheets and three subscriptions. By the end of the conversation, it has somehow been assigned an imaginary IT department, a compliance team, several security specialists and a twenty-four-hour operations centre.

The architecture diagram alone could wallpaper the office.

All because the business wanted software designed around how it actually works.

Revenue is a terrible way to decide what security you need

A six-figure business can handle extremely sensitive information.

It can also sell garden furniture.

The amount of money a company makes does not tell us what its application stores, how many people use it, what would happen during an outage or how damaging a breach would be.

A four-person payroll company may need much stronger controls than a larger business running a public catalogue of products.

A small legal firm could hold confidential documents belonging to hundreds of people. A considerably larger events company might need a private tool containing little more than schedules, supplier names and information already available on its website.

The risk comes from what the system does, not whether somebody has put “seven-figure founder” in their biography.

Even the serious frameworks understand proportionality

The people warning small businesses that everything must be “enterprise-grade” might be surprised to discover that respected security frameworks do not tell every organisation to implement every possible control.

NIST’s Cybersecurity Framework 2.0 Small Business Guide was created specifically for smaller organisations with modest cybersecurity resources.

NIST also states that the framework is not a one-size-fits-all approach. Its guidance on prioritisation tells organisations to consider their business requirements, risk tolerance and available resources when deciding what to address.

The Center for Internet Security does something similar with its Implementation Groups.

Its controls are divided into three groups based on the organisation’s risk profile and resources. Everyone begins with the foundational protections in the first group. Organisations with more sensitive data, greater exposure and more sophisticated threats add further safeguards.

That sounds suspiciously like assessing the business and applying controls that fit.

Where is the part where every local accountancy firm must immediately assemble the cybersecurity division of a defence contractor?

“Enterprise-grade” can mean almost anything

There are legitimate enterprise requirements.

A large organisation may have thousands of employees, multiple departments, offices in several countries, strict procurement rules, internal security teams, regulatory obligations and systems that cannot be unavailable for five minutes without causing serious damage.

Software built for that environment may need:

• Complex identity management
• Detailed audit trails
• Formal approval processes
• Multiple levels of administration
• Regional hosting and data controls
• Redundant infrastructure
• Specialist incident response
• Integration with dozens of existing systems
• Contracts covering uptime, support and liability

Those capabilities cost money because the problems they solve are expensive.

A small business does not automatically inherit those problems because its revenue passed an exciting number.

“Enterprise-grade” is also one of those phrases that can mean resilient, well-supported and suitable for regulated work.

It can equally mean the price has disappeared from the website and a salesperson would like to discuss your budget.

All that extra machinery needs looking after

Every additional service, account, integration and layer of infrastructure has to be configured, updated, monitored and understood.

More technology means more credentials to protect. More permissions to review. More places for information to move through. More providers that can change their pricing or terms. More things that can fail at the same time while everybody insists their particular component is healthy.

That complexity may be justified.

A payment platform serving millions of people should not be built like an internal booking tool for one small team.

The problem begins when complexity is added because it looks professional rather than because the product needs it.

A small app gets broken into lots of separate pieces because somebody read how Netflix builds software and decided to copy it.

Netflix has reasons for that complexity. A ten-person business probably does not.

Then a second hosting company is added in case the first one fails, even though nobody has checked whether yesterday’s backup actually works. An expensive monitoring tool sends hundreds of warnings that nobody reads.

The architecture diagram looks magnificent.

The former contractor still has administrator access.

Small does not mean careless

A proportional approach is not permission to ignore security until somebody complains.

A small application may still need:

• Multi-factor authentication
• Proper separation between users and customers
• Encrypted connections
• Secure password handling
• Backups that have actually been tested
• Useful logs
• Monitoring for failures and suspicious activity
• Updates for libraries and services
• A process for removing access
• A plan for what happens if something goes wrong

None of those require the business to recreate an enterprise IT department.

Managed services can handle much of the underlying work. A capable developer can configure them around the product, test the important boundaries and explain which responsibilities still belong to the business.

If the application grows, starts processing more sensitive information or becomes essential to daily operations, the controls should grow with it.

That is normal.

What would be strange is building the final infrastructure for an imaginary international empire before the first real customer has logged in.

The expensive option is not automatically the safer one

A complicated system maintained by people who barely understand it can be far more dangerous than a smaller system built from a few well-chosen services.

Buying more tools does not guarantee that anybody reviews their alerts.

Hiring more people does not guarantee clear responsibility.

Adding more approval stages does not guarantee that somebody notices an exposed credential.

Paying for the highest plan does not configure the permissions.

Some businesses spend heavily on security products while leaving the basic work unfinished. Staff share accounts. Old users keep access. Backups exist but have never been restored. Nobody knows which services contain customer information. The incident plan is a document last opened eighteen months ago.

It all looks reassuring until something happens.

Then everybody discovers which parts were controls and which parts were decorations.

Sometimes the heavier controls are justified

A small company can still require serious security investment.

If it handles financial accounts, government information, large amounts of personal data, valuable intellectual property or systems that people depend on, its size will not protect it from the consequences of getting things wrong.

Contractual requirements may also demand particular controls. So might insurers, customers, regulators or the markets where the business operates.

The correct response is to identify those requirements and build for them.

Perhaps the project needs specialist security testing. Perhaps it requires legal advice, detailed auditing, regional restrictions, stronger encryption or a dedicated person responsible for security.

Fine.

That decision should come from evidence about the business and the system.

It should not come from somebody seeing the words “custom software” and deciding the business needs every security product they have ever heard of.

What I would spend the money on first

Before buying an impressive collection of security products, I would want the boring questions answered.

What information does the application hold? Who can access it? Which parts are essential to the business? What would cause the most damage if it leaked, changed or disappeared? Which providers are involved? Who owns the accounts? Can the system be restored? Who notices when it fails?

Then spend money on the risks that appear in those answers.

For one business, the priority might be account security and reliable backups.

Another may need strict separation between customers and detailed records of every important action.

A third may discover it should not be collecting a particular type of information at all.

That work is less exciting than announcing a transformation programme. It is also considerably more useful.

Build for the business that exists

A business should not be embarrassed because its custom platform uses a small number of established services.

It should be able to explain why those services were chosen, what each one does and how the important risks are being handled.

The platform can become more sophisticated as the business, data and consequences demand it. Starting with a sensible architecture does not prevent future growth. It prevents the company from spending its current budget maintaining solutions to problems it does not have.

If somebody can price your future compliance department before asking what the application stores, keep your wallet closed.

You are being sold the costume.