Security before your first enterprise pilot: what matters

Why this matters before the pilot

Before your first enterprise pilot, security is mostly about control. Buyers usually start with simple questions: Who has access? What happens if a laptop goes missing? Where are the backups? Which outside tools touch the data?

A pilot may feel small on your side, but it reaches real people, devices, and vendors right away. Even a narrow test can involve employee laptops, admin accounts, cloud tools, support inboxes, and a few services nobody has reviewed in months. One weak spot can turn a routine question into a long, uncomfortable thread.

Paperwork does not fix weak access or a lost laptop. A founder can spend two days writing a policy and still miss the problem that matters today: a former contractor still has production access, or one engineer works on an unencrypted laptop. Buyers can tell the difference between a team that wrote rules and a team that handled the basics.

Small teams usually do better with a short list they can finish. In most cases, four areas come first: access to systems and data, laptop security, backups you can restore, and a quick review of the vendors involved in the pilot.

That order matches real risk. Old access, a stolen device, or a vendor with loose controls can slow or stop a deal fast. The fix is rarely a giant security program. It is a few habits that lower obvious risk and let you answer buyer questions clearly.

That practical approach is often the right one for this stage. Oleg Sotnikov works with lean teams in exactly this mode: fix what matters, skip the ceremony, and get to a clean, usable setup.

If you can explain who has access, how laptops are protected, how you recover data after a mistake, and which vendors are involved, you already look more prepared than many early teams.

Start with access control

The most common early security problem is simple: the wrong person keeps the wrong access for too long. For a startup heading into an enterprise pilot, this is usually the fastest work with the biggest payoff.

Start by listing every system the pilot touches. Do not stop at production. Include the tools around it too, because mistakes and account takeovers often start there. Think through email, calendar, code hosting, CI/CD, cloud accounts, admin dashboards, docs, tickets, shared drives, support tools, analytics, and billing.

Then clean up accounts hard. Remove former employees, old contractors, test users, and anything nobody can explain. Shared logins should go too. They feel convenient for a week, then nobody knows who changed a setting or exported data.

After the cleanup, cut access down to what each person needs right now. An engineer may need the repo, logs, and staging, but not billing. A founder may need billing and contracts, but not database admin. If someone asks for broad access "just in case," start smaller. You can add more later.

Turn on MFA anywhere that can unlock the rest of your stack. Email comes first. Then protect your code host, cloud account, password manager, and any admin tool tied to customer data. App-based codes or security keys are usually better than SMS.

One person should approve every new access request. In a small team, that can be the founder, CTO, or an ops lead. The tool matters less than the rule. A short ticket, a note in chat copied into a doc, or a small spreadsheet is enough if it records three things: what access the person needs, why they need it, and when you will review it again.

If a buyer asks who can reach pilot data, you should be able to answer in minutes.

Fix laptop basics first

Most early security issues start on a laptop, not on a server. One lost device, one outdated browser, or one personal app signed into a work account can create a client problem fast.

Start with the settings every laptop already has. Require a short auto-lock time and full-disk encryption on every machine, including the founder's laptop. If someone leaves a device in a taxi or at an airport, encryption and screen lock keep casual access out and buy you time.

Keep the operating system, browser, and password manager up to date. Teams love to postpone updates because restarts are annoying. That habit turns one laptop into the weak spot for everyone else.

Work and personal use should stay separate. A developer testing random browser extensions in the same profile they use for customer email is asking for trouble. Use a dedicated work login, a work browser profile, and work accounts that do not mix with family photos, shopping logins, or random downloads.

Turn on device tracking and remote wipe before you need them. It is boring setup work, but it pays off the first time a laptop disappears. Someone on the team should be able to see which devices exist, who uses them, and whether they can lock or erase them that day.

For a small team, the baseline is simple:

• screen lock after a few minutes of inactivity
• full-disk encryption enabled and checked
• auto-updates on for the OS, browser, and password manager
• device tracking and remote wipe enabled
• built-in firewall and malware protection turned on

Do not rush to buy extra software if the built-in tools already cover the basics. Windows, macOS, and modern browsers do more than many startups use. First make sure every laptop actually uses those protections.

If five people are about to join a pilot, check all five laptops in one afternoon. You will usually find the same mess: one machine without encryption, one old browser, and one person storing work passwords in a personal vault. Fixing that early is much cheaper than explaining it during a security review.

Make backups boring and reliable

Most small teams back up the easy stuff and forget the thing that would hurt most. Start by naming the data you cannot lose for even one day. That usually means the production database, source code, environment configs, delivery docs, and any customer files you store.

A reasonable backup scope often includes code repositories and deployment scripts, product docs and runbooks, infrastructure settings such as DNS records and server configs, and customer data stored in databases or file storage. If you depend on exports from third-party tools, include those too.

Keep at least one copy away from the main system. If your app, backups, and admin access all live in the same cloud account, one bad deletion or one locked account can ruin your week. Use a separate location, a separate account, or both. You do not need a fancy setup. You need one that still works after a bad day.

Test a restore before the pilot starts. This matters more than adding another backup job. Pick a real scenario and run it end to end. Restore a recent database snapshot into a safe environment. Pull code onto a clean laptop. Open the restored docs and configs. Time the whole process. If it takes four hours, write that down. Now you know what recovery actually looks like.

Give one person ownership. When everybody owns backups, nobody checks them. That owner does not need to run every step by hand, but they should confirm each week that backups ran, storage is not full, and the restore steps still match the current product.

A short weekly check is enough:

• confirm the last successful backup time
• verify the offsite copy exists and looks complete
• review the restore notes or rerun a small restore test

Boring backups are the goal. When the pilot starts, your team should focus on delivery and customer feedback, not scramble to rebuild data you assumed was safe.

Review vendors with a short list

Small teams usually carry more vendor risk than they think. The trouble rarely starts with some advanced attack. It starts with a tool nobody reviewed, a former contractor who still has admin access, or a service that stores customer data even though the team barely uses it.

List every vendor that stores company or customer data, sends email on your behalf, or touches sign-in. Include the obvious ones like cloud hosting and source control, and the forgettable ones like form tools, analytics, support chat, and file sharing.

For each vendor, read three things: its security page, its data terms, and the admin settings you control yourself. You do not need a long audit. You need plain answers.

Keep one simple sheet with one row per tool. Track what data the tool stores, whether it touches auth or production, which admin controls you can turn on, whether vendor staff can access your data, and whether you still need it for the pilot.

That last question matters more than most teams expect. If a tool is not required for the pilot, cut it. Every extra vendor adds another login, another place where data can spread, and another support team that might have some level of access.

Pay close attention to staff access inside the vendor. Some services allow support engineers or internal admins to view customer data in limited cases. That is not always a deal breaker, but you should know the rule, know how they approve access, and know whether you can limit or disable it.

Teams often find easy wins here: two analytics tools doing the same job, a dormant support widget still installed on the site, or a file-sharing app full of old exports. Removing those tools lowers risk faster than writing ten pages of policy.

If you work with a Fractional CTO or another experienced operator, this vendor sheet becomes a useful decision tool. It tells you what to keep, what to lock down, and what to remove before the pilot starts.

A simple order of work

Four focused weeks beat two months of policy writing. The goal is not to look mature. The goal is to remove the obvious risks that can derail a deal or turn a small mistake into a real incident.

Start with identity. If former contractors still have access, or two people share one admin login, fix that first. Turn on MFA for email, cloud accounts, code repositories, and password managers. Remove stale access the same day you find it.

A simple order works well:

• Week 1: review every account that can touch customer data, billing, source code, or production systems.
• Week 2: patch laptops, force screen locks, enable disk encryption, and limit local admin rights.
• Week 3: set automatic backups for the systems that matter most, then test one file restore and one full restore.
• Week 4: review your vendors with a short checklist and close the biggest gaps first.

This sequence makes life easier. Clean up accounts first, and fewer people can make changes or leak data. Lock down laptops next, and a lost device becomes a hassle instead of a breach. Test backups before the vendor review, and you already have a clear answer when a customer asks how you recover.

A small team can often finish the first two weeks faster than expected. One founder or outside CTO can usually clean up accounts in a day or two, then spend the next few days fixing laptop basics. Backups only drag on when nobody owns them.

Write policy after the controls exist. A short access rule that matches real settings helps. A long document nobody follows just adds noise. Keep the rules short, name one owner for each control, and check them monthly until the pilot goes live.

Mistakes that waste time

Teams often spend energy on work that looks serious but does little to lower risk. The most common mistake is polished admin work before basic controls.

A classic example is writing a long security policy while old contractors still have admin access to code, cloud, email, or the password manager. The document will not protect customer data. Cleaning up access will.

The usual time-wasters are easy to spot:

• shared logins that hide who changed what
• backups that run every night but have never been restored
• new tools added right before the pilot because they seem useful
• personal laptops used for customer work with weak local security
• broad admin rights kept for daily work because changing roles feels annoying

Shared accounts are especially bad. They save five minutes today and create hours of confusion later. If someone leaves, you cannot remove only their access. If something breaks, you cannot trace the action to one user.

Untested backups waste time in a quieter way. A green checkmark every morning makes people feel safe. Then a file gets deleted, a laptop dies, or a bad deployment lands, and nobody knows whether recovery will work. A backup you never restored is just a hopeful file.

Last-minute vendors create the same kind of mess. Every new tool gives you another place to review permissions, data handling, and contract terms. Right before a pilot, that extra work rarely pays off.

Personal laptops cause trouble for the same reason. If one device has weak local security, the whole team ends up answering hard customer questions with bad facts. It is much faster to require updates, disk encryption, screen locks, and separate work accounts before customer data touches the machine.

If a task does not lower risk this week, move it down the list. Fix access. Lock down laptops. Test a restore. Keep the vendor stack small.

A short pre-pilot checklist

Buyers rarely ask for a thick folder of policies on day one. They want to see that your team handles the basics with care. If you can answer the checks below with a clear yes, you are in much better shape.

• Each person uses their own account for work systems.
• Every admin account uses MFA, and someone on the team owns it.
• Every work laptop locks quickly, uses disk encryption, and installs updates without long delays.
• Backups run on a schedule you trust, and your team has already restored something from them.
• You can explain every vendor in the pilot stack in one or two sentences.

This list is short on purpose. A small team can finish most of it in days, not months.

Here is a simple example. If your pilot uses Google Workspace, GitHub, a cloud host, and one support tool, you should know who has admin rights in each one, whether MFA is on, whether laptops are encrypted, where backups live, and what customer data reaches the support tool. If you cannot answer one of those in a minute, fix that gap before the pilot starts.

The work is plain, a little boring, and very effective. Enterprise buyers usually notice the basics first.

A realistic small-team example

A five-person startup is about to start a paid pilot with its first enterprise customer. The product works, the demo went well, and then the customer asks, "How do you handle security?" The team does not need a thick policy set. It needs a few fixes that lower real risk.

The company uses the same tools most small teams use: email, team chat, code hosting, and one cloud host. Two early contractors left months ago, but their accounts still exist. One shared admin login sits in a team note because "everyone needs it sometimes." Buyers notice that kind of mess fast.

In one week, the founders clean up the basics. They delete the old contractor accounts, turn on MFA everywhere, and give each person their own login with only the access they need. If someone leaves later, the team can remove one account instead of changing a secret that half the company knows.

They fix laptop settings next. Every laptop gets full-disk encryption, auto-lock, and system updates turned on. Then they test the step many teams skip: a restore. One engineer pulls a recent backup into a clean setup and checks that the app and data actually come back.

That test takes an afternoon. It also saves them from assuming backups work because a dashboard says they do.

The team reviews its vendors too. One tool still has access to customer data, but nobody has used it in three months. They remove it instead of keeping one more place where data can leak.

By the time the customer asks follow-up questions, the startup can answer clearly:

• each person has their own account
• former contractors no longer have access
• laptops are encrypted and lock automatically
• backups run, and the team has tested a restore
• unused vendors do not keep access

This does not make the startup perfect. It does show something buyers care about: the team pays attention, fixes obvious gaps, and handles the basics well enough to earn trust.

What to do next

Most small teams do not need a thick security handbook before a pilot. They need a few short rules people will follow this week. Write them in plain English and tie them to real work: who gets admin access, how laptops stay updated and encrypted, where backups go, and when a new vendor needs review.

Put one person in charge. That owner does not need to do every task alone, but they should keep the list current and make sure nothing gets skipped. Split ownership too widely and the basics start to drift.

A good next step looks like this:

• write a one-page set of rules for the team you have now
• make a simple inventory of admin accounts, work laptops, backup jobs, and vendors that touch customer data
• fix the obvious gaps first, then do one more check before any customer data enters the pilot
• leave the low-risk paperwork for later

This work usually pays off fast. A quick review often finds stale access, missing disk encryption, backup jobs that no longer run, or a vendor that got approved with no real check. Buyers care about those gaps more than a policy nobody on your team has read.

If you want an outside review, Oleg Sotnikov at oleg.is works with startups as a Fractional CTO and advisor on practical security, infrastructure, and team operations. For a small team heading into its first enterprise pilot, that kind of second pass can save a week of last-minute cleanup.