NIS2 is a risk-reduction programme, not a box to tick after buying a tool. For an SMB, the most useful starting point is often concrete: know which access rights could stop operations, who uses them, how they are protected, and how to revoke them.
This guide provides a practical starting checklist. It does not replace a legal scope assessment or professional advice.
1. Check your scope
Before choosing tools, record the information needed to determine whether your organisation is directly or indirectly affected:
- sector and services provided;
- company size and other criteria in the applicable rules;
- role as a supplier, subcontractor, or service provider to an organisation in scope;
- country and national transposition rules that apply;
- security requirements already included in customer contracts.
Do not reach a conclusion from headcount alone. An SMB may not be directly subject to NIS2 while still facing security requirements from customers or partners.
2. Build a simple inventory
Start with an inventory sheet shared by management and whoever handles IT. For each activity, record:
- Activity or service — what must keep running;
- System used — email, accounting, hosting, DNS, backups, or business tools;
- Owner — the person who decides and follows up;
- Critical access — admin account, service account, or supplier access;
- Dependency — provider, supplier, or third-party system;
- Evidence — policy, review, test, or saved record.
Review the list at least annually and after a material change: a new tool, new provider, administrator departure, or business change.
3. Map identities and privileges
For each critical access, check five points:
- the account owner is identified;
- every authorised user is known;
- the privilege level is justified;
- authentication and recovery are documented;
- revocation can happen quickly.
Remove unused accounts. Replace shared accounts where possible; when a technical account must remain shared, document its use, owner, and secret-rotation process.
An encrypted local vault such as Soclyde can help organise this scope: generate unique secrets, store them on the organisation’s devices, and share them in a controlled way with authorised people. It does not remove the need to manage accounts inside each service.
4. Apply priority measures
Start with measures the team can verify:
- one unique password per service;
- a strong primary passphrase for the vault;
- multifactor authentication enabled wherever a service supports it;
- administrator rights separated from everyday use;
- periodic account and privilege reviews;
- an onboarding, role-change, and offboarding process;
- backups whose restoration has been tested.
Soclyde primarily addresses the risk of credentials being reused, scattered in spreadsheets, or sent through unsuitable channels. It does not replace MFA, endpoint management, patching, or monitoring.
5. Assign responsibility
Security should not depend on one person who “knows the passwords”. At minimum, name:
- a management owner;
- an operational security contact or identified provider;
- owners for each critical activity and system;
- an incident contact, with a backup contact.
Write a short policy: who can request access, who approves it, where the secret is stored, when the right is reviewed, and how it is removed. A rule people understand and follow is more useful than an ambitious document nobody consults.
6. Prepare for incidents and continuity
A NIS2 checklist does not stop at passwords. Test at least once:
- revoking a compromised account;
- recovering a vault and its backups;
- contacting the provider in an emergency;
- deciding what to do if email or a business system is unavailable;
- preserving useful material for incident analysis.
Record the date, participants, result, and corrective action. This evidence makes progress visible and prevents gaps from being discovered during a crisis.
A 30-day starting checklist
- [ ] Name the management security owner.
- [ ] List critical activities, systems, and providers.
- [ ] Review administrator accounts and remove orphaned accounts.
- [ ] Enable MFA on services that support it.
- [ ] Replace reused secrets and centralise them in an encrypted vault.
- [ ] Define onboarding, role-change, and offboarding procedures.
- [ ] Test one revocation, one restore, and one unavailability scenario.
- [ ] Keep decisions, owners, deadlines, and test results.
What Soclyde contributes
Soclyde supports one specific part of the programme: protecting and organising credentials and other operational secrets. A local-first approach reduces reliance on a central server for this data, while the company remains responsible for its devices, backups, accounts, and procedures.
Use Soclyde as one building block in your action plan, not as a promise of automatic compliance. The useful questions are: which risks have we reduced, what evidence can we show, and what action remains?
