Cyber Risk Assessment for Indian Businesses, Step by Step 

Small confession first. I used to think a cyber risk assessment was some guy in a suit running a scary scanner, then dropping a 90-page PDF that nobody ever opens. 

That's the bad version, though. A good one is boring. Really boring. Also way more useful.

Here's the kind of thing it catches. Your accounts person gets a mail saying a vendor changed their bank details. She updates it, because why wouldn't she? Two weeks later the actual vendor calls, a bit annoyed, asking where their money is. Nobody got "hacked" like in the movies, mind you. One email. That's all it took.

Three questions. What do we have that matters? What could hurt it? How bad would that be?

That's it, really. Everything else is just answering those properly instead of guessing.

You don't end up with some dramatic report. You end up with a list. Ranked. Every risk has a name next to it and a decision: fix it, shrink it, push it to an insurer, or leave it alone on purpose with a senior person nodding along.

People call this cyber risk management. Sounds very corporate, I know. It just means working out what to spend on first. You can't protect everything equally. Plenty of smaller firms just buy whatever the last salesperson pitched. Which, sure, is a strategy.

If you want a neutral guide on how the pros do it, the NIST Cybersecurity Framework is free and way easier to read than you'd expect. Also keep CERT-In bookmarked. They look after national incident response in India, and it's better to know their reporting rules before you ever need them.

Yeah, I know, it sounds like paperwork. Skip it, though, and the assessment either drags on for months or ends up checking the wrong stuff entirely.

Scoping is just drawing a line. Head office only, or the branches and plants too? Cloud accounts? The ERP? That mobile app a freelancer built three years ago and nobody has touched since? Pick, write it down, and move on.

Think about what you're protecting in plain business terms. For an online store, it's customer data and the checkout page. For a small NBFC, loan records and the app. For a factory, maybe the machines themselves, which often run software so old that nobody wants to restart them.

And get someone senior to say out loud that this matters. Otherwise, the IT team spends weeks chasing other departments and hearing "will send tomorrow." (Tomorrow never comes, by the way.)

Also jot down which rules apply to you. If you hold personal data, India's Digital Personal Data Protection Act, 2023, is relevant, and you should check where its rules stand for your sector right now. Banks, NBFCs, insurers and SEBI-regulated firms usually have regulator expectations on top. I'm not going to guess at specifics. Ask your compliance person or a lawyer.

This one catches people off guard. Nearly every company finds something it forgot it had.

An old test website that's still live. A cloud storage bucket from a project that ended two years ago. A login belonging to someone who left in 2022 and, funnily enough, still works fine.

So, make the list. Servers, laptops, phones that check work email, SaaS tools, databases, websites, payment gateways. And the shadow stuff, like the free tool somebody in marketing signed up for using their office email. Everyone has a few. Everyone.

Next to each thing, write who owns it and how much it matters. Low, medium, and high is plenty. The server with KYC documents or Aadhaar copies obviously ranks above the one hosting last year's event microsite. Data beats hardware. You can buy another laptop, but trust is a lot harder to rebuy.

Vendors go on the list too. Your CA firm, payroll provider, logistics partner, the ad agency. If their access to your data is sloppy, it's your problem, even though it's not your server.

Step 3: What could actually go wrong?

Now put yourself in the attacker's chair for a bit. Don't get paranoid, just be realistic about what actually shows up in Indian businesses.

Phishing, mostly. A fake mail pretending to be a vendor or a courier company or the GST portal. A WhatsApp message "from the MD" asking for an urgent transfer. Right beside that sits business email compromise, which is the vendor story I started with.

Then ransomware, where your files get locked and someone wants money to unlock them. It's hit hospitals, factories, tiny firms, pretty much everyone. The 2022 attack on AIIMS Delhi is probably the best-known public case. It showed how fast things stop when core systems go down.

And the usual suspects. Stolen passwords. Cloud storage left open to the entire internet. Software nobody patched. Now and then, an unhappy employee.

For each asset, ask which of these could realistically reach it. A public website faces different stuff than an internal accounts system. You're matching threats to assets, not writing a thriller.

Where a vulnerability assessment comes in

This is where a vulnerability assessment is handy. It's a sweep, mostly automated, across your systems, apps and networks, hunting for known weak spots. Missing patches. Old software. Bad settings. Ports sitting open for no good reason.

Step 4: Check the protections you already have

Controls are the safeguards you've already got. Password rules, multi-factor login, backups, firewalls, staff training, who can get into what, and a plan for when things break.

The catch is you have to check if they work, not whether they exist. A backup policy isn't a backup you've actually restored. MFA doesn't mean much if it skips the finance team's mailboxes and your admin accounts.

This part gets a little awkward, honestly. Somebody says, "yeah, we have that," and somebody else quietly goes "do we?"

For each high-value asset, I'd ask three simple things. Who can reach it? How would we notice if someone did something odd? How fast could we get it back if it vanished tonight? If a team watches your logs and alerts, in-house or through a managed security operations centre (SOC), write that down here. How fast you spot trouble changes how bad it gets.

And if you want a bigger-picture read on your security overall, not just one system, a cybersecurity maturity assessment works well next to the risk review.

Where penetration testing comes in

Penetration testing earns its place here. Skilled people, with your permission, try to break in the way a real attacker would. They string small weaknesses together and push on your controls to see what gives. You get an actual story of how a break-in would go, start to finish.

A vulnerability assessment says there are some unlocked windows. A pentest says I climbed through that one, walked into the server room, and copied your customer database. Much more convincing in a boardroom, by the way.

Penetration testing vs a risk assessment (and where VAPT fits)

People mix these up all the time, so I'll be blunt. The risk assessment is the big picture: your business, your assets, what matters most. Penetration testing and vulnerability assessment are technical checks that feed into it.

Think doctor. The overall health review is the risk assessment. Blood work and scans are the VAPT. Blood work can't tell you about your lifestyle, and a chat about your lifestyle can't tell you your cholesterol. You need both.

VAPT just means vulnerability assessment and penetration testing bundled together. If you want to see what usually gets tested, our VAPT services page covers it.

The order that makes sense to me: risk assessment first so you know what's critical, targeted VAPT on those systems next, then back to the register to update it with whatever the tests turned up.

What this looks like in Indian businesses (made-up, but realistic)

These aren't real clients. Just scenarios I reckon are close to the real thing.

Say you run an online fashion brand out of Bengaluru. Website, payment gateway, customer database, a couple of courier integrations. You'd worry about checkout tampering, stolen customer data, and hijacked admin accounts. A vulnerability assessment on the site, a pentest on checkout and the admin panel, and phishing training for the support team, because they open mails from strangers all day.

A mid-sized manufacturer in Gujarat is a different animal. The sensitive systems aren't only office computers. They're the machines on the production floor, likely old and rarely updated. If the line stops, that can cost way more than a data leak. So you'd look hard at how well office IT is separated from the factory side, and what happens if the ERP is down for three days.

What you should end up with (and who actually does the work)

A decent assessment leaves you with real things in your hands. Not just a feeling that something got done.

Mainly, you want a scope note so everybody remembers what was covered, an asset list with owners, a rundown of threats and weak spots, a look at where your controls fall short, and the risk register itself with ratings and decisions. On top of that, a short action plan, with names and dates. If a pentest was part of it, there's a separate technical report on what was found and how to fix it, plus a version for people who'd rather not read technical details.

Who does what? It gets messy if nobody decides early. Leadership sets how much risk is okay, approves the money, and signs off on anything being accepted. Whoever runs IT or security drives the process and chases the fixes. Department heads own the data and systems in their area because they know what really matters day to day. HR and legal come in for people, contracts, and compliance.

And an outside team is worth having, mostly because they don't share your habits. After a while, everybody in a company stops seeing the weird old server in the corner. A fresh pair of eyes still does.

How often should you redo it?

Once a year, minimum. That's the usual advice, and it's fair enough. But your business doesn't sit still between reviews, so yearly alone won't cut it.

Redo it when something big shifts. New cloud provider. New app launch. A merger. A key vendor change. An incident, or even a near miss. New rules that apply to you. Any of those is reason enough.

In between, run lighter checks. Vulnerability scans are done every quarter or after major releases. Penetration testing at least yearly for critical systems and after big changes. One proper check-up a year, a few smaller ones along the way.

The good and the bad of doing it properly

The good stuff is real. Money goes where it counts. You can explain your decisions to the board, auditors, clients, and insurers with evidence instead of vibes. Silly gaps get caught early. And bigger customers who send you security questionnaires tend to trust you more.

The bad stuff, I won't pretend otherwise. It eats people's time, and people are already busy. It's uncomfortable since it shows things nobody wanted to look at. The snapshot goes stale quickly if you don't update it. And if you do the whole exercise and never act on it, you've basically paid to feel guilty.

I still think it's worth it. Only if you follow through, though.

Mistakes I keep seeing

Treating it as a one-off project. Doing it only to tick a compliance box. Forgetting vendors and cloud accounts. Marking everything "high" because nobody wants the blame, which makes the ranking useless.

And my favourite: buying an expensive tool first and working out the problem afterwards. Start with the questions. Tools can come later.

If you take one thing from all this, let it be that it doesn't have to be big or perfect. A modest, honest look at your five most important systems, done this quarter, beats a gorgeous framework that never leaves the planning stage.

Key takeaways

•  A cyber risk assessment answers three questions: what matters, what could go wrong, and how bad would it be.
• Scope first. Decide what's in and out, and get leadership behind it.
• Build a real asset inventory, including data, vendors and forgotten shadow tools.
• Match realistic threats like phishing, ransomware, payment fraud and stolen logins to your assets.
• A vulnerability assessment finds known weaknesses broadly. Penetration testing shows what an attacker could actually do.
• VAPT feeds into a risk assessment. It doesn't replace one.
• Give every risk an owner, a deadline and a decision: reduce, avoid, transfer or accept.
• Reassess at least yearly, and after big changes like new apps, vendors, mergers or incidents.
• Check your own sector regulator's requirements directly instead of relying on generic checklists.

Frequently asked questions

How do you do a cyber risk assessment step by step?

Start with scope. Decide which systems, locations, and data are in. Then list your assets and mark how much each one matters. After that, work out the realistic threats and hunt for weak spots, using vulnerability assessments and, for the critical systems, penetration testing. Check whether your current controls actually work. Then score each risk on likelihood and impact, pick what to do (reduce, avoid, transfer, or accept), give every item an owner and a deadline, and keep it all in a risk register you actually go back to.

What's the difference between VAPT and a risk assessment?

A risk assessment looks at the whole business and decides which risks matter most and what to do about them. VAPT, short for vulnerability assessment and penetration testing, is a set of technical tests that find and prove weaknesses in specific systems. The results go back into the risk assessment. So one is the strategy, and the other is the evidence. Most organisations need both.

What deliverables should a risk assessment produce?

You should get a scope statement, an asset inventory, a summary of threats and vulnerabilities, a control gap review, a risk register with ratings and decisions, and a prioritised action plan with owners and timelines. If penetration testing is included, ask for the technical findings report and an executive summary too.

Do small Indian businesses really need this?

Yes, though it can be lighter. Smaller firms often get picked on precisely because their defences are thinner and attackers assume nobody's watching. A focused look at your handful of critical systems and key vendors is a sensible place to start.