Somewhere in your vendor checklist there's a line that reads "ISO 27001 certificate: yes or no". For us the answer is no. Conimex IT is a five person software team in Belgrade, and we've never been certified against ISO 27001, the international standard for managing information security.
What we do have is a short list of habits you can check one by one: your code and servers stay in your name, everyone logs in with their own account, real data never touches a test server, backups run every day and get restored on purpose, and if something goes wrong you hear about it from me before anyone starts fixing it. This post walks through each one, says where a certificate would beat us, and gives you the questions to ask any small vendor, us included.
Why a small vendor often has no ISO 27001 certificate
The plain reason: our clients have never asked for it. Where it does show up is procurement. Formal tenders and supplier forms list it as a requirement, usually long before anyone has looked at how the vendor actually works.
A certificate isn't a one time purchase. Getting certified means building and documenting a management system, then passing a two stage audit, and for a small company that usually takes around six months. After that come surveillance audits every year and a full recertification every three years. None of that is a bad idea. It's a cost that a five person team pays mostly in founder time, and so far no client has asked us to.
The current version is ISO/IEC 27001:2022. Its Annex A lists 93 controls, grouped as organizational, people, physical and technological. If you saw a headline about a 2026 edition, that wasn't 27001. The standard that changed this year is ISO 9001:2026, the one for quality management.
What NIS2 actually asks you to check
If you're in the EU and your company falls under NIS2, the EU directive on cybersecurity for essential and important entities, this part matters more than the certificate.
Article 21 of NIS2 lists supply chain security among the measures you have to take, meaning the security of your relationships with direct suppliers and service providers. Article 21(3) then says what to look at: the vulnerabilities specific to each supplier, the overall quality of their products and cybersecurity practices, "including their secure development procedures".
ISO 27001 isn't mentioned anywhere in that text. The directive asks you to look at what your vendor does. A certificate is one way to show that, and an honest description of practice you can verify is another.
How we work, and how you can check each part
Your code, servers and accounts stay in your name
We prefer everything to live on the client's side: the code repository, the hosting account, the domain, the app store accounts. If the relationship ends, you change who has access and nothing has to be handed back. Some clients don't have the technical setup to create those accounts themselves, and then we hold them on the company account until they're ready to take them over.
How to check: ask who owns each account, and whether you could lock the vendor out tomorrow without asking them for anything.
Everyone has their own login
Nobody on our team shares a login to your code or your servers. Most of our accounts also require 2FA, a code from your phone on top of the password, so a stolen password alone doesn't get anyone in. Passwords and access keys live in Apple Passwords rather than in chat messages.
How to check: look at the user list on your repository and hosting. You should see one name per person, not a shared "dev" account.
Real data stays in production
Our test environments always run on made up data. Real customer records don't get copied to a developer's laptop or to a test server, ever. On top of that, the disks on our work machines are encrypted, and everyone on the team and every outside collaborator signs a confidentiality agreement.
How to check: ask where the data on the test server came from. "We copied production and changed some names" is the answer you don't want.
Backups every day, and restores we actually try
We back up databases once a day. On several projects we also restore a backup once a month, on purpose, to confirm the restore actually works. A backup you've never restored is a hope, not a backup.
How to check: ask when the vendor last restored a backup and how long it took.
A second developer reads every change
We aim for an independent code review on every change, so no code goes in that only its author has seen. That's where things like a missing permission check usually get caught. We also try hard not to rotate developers in and out of a project, which we wrote about in what happens if your developer leaves.
How to check: ask to see a merged change and the review comments on it.
If something goes wrong, you hear it first
When a security problem turns up, I tell the client myself, straight away, and only then start on the fix. Not after the patch is out, not in the monthly report. You can't make decisions about your own risk if your vendor is quietly deciding for you. The EU now writes the same instinct into law for product makers: under the Cyber Resilience Act, an actively exploited vulnerability needs an early warning to the authorities within 24 hours.
How to check: ask the vendor to describe the last security problem they found and when the client heard about it. If the answer is "we've never had one", keep asking.
The admin routes we found in someone else's code
Here's ours. We took on a brownfield project, meaning an application that was already built and running when it reached us. Going through it, we found admin routes, the addresses behind the admin panel, that had no protection at all. Anyone who knew or guessed the address could reach them. That opened the door to data theft and to real financial damage. Luckily, nothing was stolen.
We started fixing it the moment we saw it. Closing the routes was the easy part. The part that matters more is what we changed afterwards: our automated tests now check for exactly this, so an unprotected admin route fails the build before it can reach production again.
I'm telling this story because a vendor's security doesn't show in a clean record. It shows in what they do the day they find a hole.
Where a certificate would beat us
A certificate doesn't make software secure, but it does force regularity, and that's where a small team is weakest.
- Penetration tests. Two of our projects went through a penetration test, where an outside team deliberately tries to break into the application, one of them for a bank. Running them regularly on every project is hard for a team our size.
- Removing access. Depending on the client, either I remove our access at the end of a project or the client does. Our rule is two weeks at most. That's a long time for a former vendor to keep a key, so if a shorter deadline matters to you, put it in the contract.
- Dependency updates. Critical security fixes in the libraries and packages a project depends on go out right away. Everything else gets a routine update once every six months. That routine is a floor, not a target, and it's the item on this list we'd most like to tighten.
If your procurement rules require an ISO 27001 certificate, full stop, then we're not your vendor and this post won't change that. If they ask you to assess the supplier's actual practice, which is what NIS2 asks, then the list above is something you can check in an afternoon.
Questions to ask any vendor without a certificate
- Who owns the code repository, the hosting and the domain, and could you remove the vendor's access without their help?
- Does every person have their own account, and which accounts require 2FA?
- Where are passwords and access keys stored?
- Does real data ever leave production?
- When was a backup last restored, and on which project?
- Who reviews code before it's merged?
- How quickly is access removed when someone leaves the project?
- When a security problem is found, who tells you, and how soon?
- Has any of their projects had a penetration test, and what did it find?
Our answers are in this post. If a vendor can't answer most of these in a short call, that tells you more than a certificate would.
Working with a vendor that shows its work
We build custom web and mobile software in Laravel, React and React Native, for clients in the EU and the US, and we're happy to walk your security or procurement team through any of the practices above before you sign anything. You can see what we've built in our case studies, and if a supplier review is coming up, write to us at [email protected] and we'll go through your questionnaire with you.