Access control: who sees what in your systems
Who has access to what across your company's systems? If the answer depends on someone's memory, control already does not exist. In 67% of the security incidents Sophos investigated over the past year, the root cause was identity: valid logins, shared passwords, access nobody revoked. Today's intruder does not break the door down. They walk in with the key.
Why does the intruder prefer to log in rather than break in?
Because it is cheaper and nobody notices. The Sophos Active Adversary Report 2026, based on 661 real incident response cases across 70 countries, shows that 67% of successful attacks began with identity: stolen credentials, brute force or phishing. In 59% of those cases, the company was not using multi-factor authentication.
That is the part worth sitting with. The dominant attack path is not a vulnerability in your software. It is a credential that works, used by someone it does not belong to, through a front door that never asked for a second factor.
The bill arrives in operational terms long before it arrives in legal ones: days of halted operation, customers to notify, a possible regulatory fine, and a reputation that took years to build. For a smaller company the absolute numbers are lower than the headline breach figures, but the relative impact is usually worse.
Where do smaller companies lose control of access?
Almost never in one big mistake. Control gets lost in small decisions nobody recorded. Four patterns come up repeatedly.
The shared login. The ERP has a "sales" user that eight people use. It is cheaper on licenses and nobody knows who changed that order.
The open spreadsheet. The pricing, margin or salary spreadsheet sits in shared storage, accessible to anyone with the link. It was set that way to solve one urgent request and it stayed.
The former employee with an active account. Offboarding triggers HR, payroll and the badge. System access gets left for later, and later becomes never.
The owner as sole administrator. At the opposite extreme, everything depends on one person. Holidays, illness or simple overload turn into a bottleneck and a continuity risk.
None of these patterns comes from bad faith. They come from systems that were never designed to answer the basic question: who can see and change each piece of information?
What does access control look like as an architecture decision?
It means treating access as part of the system's design, not as configuration you tune afterwards. In practice, four elements.
Profiles by role, not by person. The salesperson sees their customers and quotes. Finance sees accounts and reconciliation. The manager sees the consolidated view. When someone changes role, they change profile, without depending on anyone's memory. That is least privilege: each person reaches what they need to work, and nothing beyond it.
A lifecycle tied to offboarding. Revoking access belongs in the same flow that switches off the badge and the payroll entry. If offboarding is manual, revocation is a checklist item with an owner and a deadline. If there is an internal system, it is automatic.
An audit trail. Every sensitive record keeps who viewed it, who changed it and when. The trail exists to reconstruct what happened when something goes wrong, not to watch people. Without it, every incident becomes opinion.
Strong authentication at the door. MFA on the systems holding sensitive data and, where possible, single sign-on, which cuts the number of passwords in circulation. The Sophos figure is worth repeating: 59% of the companies that were attacked had no MFA.
None of this is an off-the-shelf product. These are decisions about how the system works. A security tool protects infrastructure; it does not decide who should see your profit margin. That decision is yours, and the system needs somewhere to record it.
Where do you start without stopping the operation?
Start with the inventory, which fits in an afternoon. Three columns: the systems and spreadsheets the company uses, the people with access to each one, and each person's level of access. The first version will have gaps. It does not matter. It already reveals the accounts of people who left, the shared logins and the sensitive data that is open too wide.
Then revoke the obvious and name an owner for each system. The owner approves new access and reviews the list each quarter. Put revocation into the offboarding checklist with a 24-hour deadline.
A hypothetical but common scenario: a distributor with 38 employees, an ERP, a CRM and shared storage. The inventory turns up a salesperson who left five months ago with an active CRM account, a cost spreadsheet readable by the whole company, and one ERP login used by eight people. No incident has happened yet. Closing those doors today costs a few hours of work. After an incident, the bill starts at days of halted operation.
The next step, as the operation grows, is to take those rules out of the checklist and put them in the system. That was the path at Colo Saúde, where patient records require each profile to see exactly what the role permits, and at Repap On, which controls documents for large corporations with profile-based permissions and a complete trail.
Frequently asked questions
My whole team works from the same spreadsheets. Is that an access problem?
It is, and one of the most common. A shared spreadsheet does not separate who can view from who can edit, keeps no reliable history of changes, and circulates by email and chat with no control. You do not have to abandon spreadsheets overnight: start by restricting the ones holding sensitive data — prices, salaries, customer records — and migrate those first into an environment with access profiles.
Can a no-code system support serious access control?
It can. Mature platforms offer profiles, per-record permissions and an audit trail. Security does not live in the tool's label, it lives in the design: who defined the profiles, what each one sees, how access gets revoked. A badly designed custom system is less secure than a well-architected no-code one.
I don't have an IT team. Who administers this?
The inventory and the review routine are management work, not IT work: the owner of each system can be the manager of the department that uses it. The technical part — structuring profiles, automating revocation, configuring MFA — is a one-off and can be done by a partner. What cannot be outsourced is the decision about who should access what. That one is yours.
Who sees what is your decision, not the tool's
Access control is not an information security project with a complicated name. It is the part of your system's architecture that answers who views, who edits and who approves. When that answer lives in the design, Friday's offboarding does not become Monday's vulnerability.
If you cannot say today how many people can see your company's profit margin, that is a good place to start. The Operational Architecture Diagnostic is a 30-minute conversation to map how your systems handle these decisions and where the open doors are: talk to Yowpi.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No strings attached.
Book a diagnostic