PKF AvantEdge

Tag: ISO27001 (Page 1 of 3)

Major Changes of PCI v4

March 6, 2024 / / 0 Comments

So now as we approach the final throes of PCI-DSS v3.2.1, the remaining 3 weeks is all that is left of this venerable standard before we say farewell once and for all.

PCI-DSS V4.0 is a relative youngster and we are already doing hours of updates with our customers on the things they need to prepare for. Don’t underestimate v4.0! While its not a time to panic, it’s also not a time to just lie back and think that v4.0 is not significant. It is.

Below is a table that provides an insight of the major changes we are facing in v4.0.

Bearing in mind that most of the requirements now start off with keeping policies updated and document roles and responsibilities, the major changes are worth a little bit of focus. In the next series of articles, we will go through each one as thoroughly as we can and try to understand the context in which it exists on.

Let’s start off the one on the top bin. Requirement 3.4.2.

Req. 3.4.2: When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need

PCI v4.0

Ok, we have underlined and emphasized a few key points in this statement. Because we feel that is important. Let’s start with what 3.4.2 applies to.

It applies to: Remote Access

It requires: Technical Controls

It must: PREVENT THE COPYING/RELOCATION

Of the subject matter: Full Primary Account Number

In v3.2.1 this was found in section 12.3.10 with slightly different wordings.

Req 12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements.

PCI v3.2.1

I think 4.0, aside from the relocation of the requirement to the more relevant requirement 3 (as opposed to requirement 12, which we call the homeless requirement for any controls that don’t seem to fall into any other earlier requirements), reads better. Firstly, putting it in requirement 3 puts the onus on the reader to consider this as part of protection of storage of account data which is the point of Requirement 3. Furthermore, digging into the sub-requirement, 3.4 section header states: Access to displays of full PAN and ability to copy PAN is restricted.

This is the context of it, where we find the child of this 3.4 section called 3.4.2 and we need to understand it first, before we go out and start shopping for the first DLP system on the market and yell out “WE ARE COMPLIANT!”

3.4 talks about displays of FULL PAN. So we aren’t talking about truncated, or encrypted PAN here. So in theory, if you copy out a truncated PAN or encrypted PAN, you shouldn’t trigger 3.4.2. Its specific to full PAN. While we are at it, we aren’t even talking about cardholder data. A PAN is part of cardholder data, while not all cardholder data is PAN. Like the Hulk is part of the Avengers but not all Avengers are the Hulk. So if you want to copy the cardholder name or expiration date for whatever reasons like data analysis, behavioural prediction, stalking etc…this isn’t the requirement you are looking for.

Perhaps this is a good time to remind ourselves what is Account Data, Card Holder Data and Sensitive Authentication Data (SAD).

The previous v3.2.1 doesn’t actually state ‘technical controls’, which goes to say that if it’s a documentary controls, or a policy control, or something in the Acceptable Use Policy, it can also pass off as compliant. V4.0 removes that ambiguity. Of course, the policy should be there, but technical controls are specific. It has to be technical. It can’t be, oh wait, I have a nice paragraph in section 145.54(d)(i)(iii)(ab)(2.4601) in my information security acceptance document that stated this!

So these technical control(s) must PREVENT copying and relocation. Firstly just to be clear, copy is Ctrl-C and Ctrl-V somewhere else. Relocation is Ctrl-X and Ctrl-V somewhere else. Both has its problem. In copying, we will end up PAN having multiple locations of existence. In relocation, the PAN is moved, and now systems accessing the previous location will throw up an error – causing system integrity and performance issues. Suffice to say, v4.0 demands the prevention of both happening to PAN. Unless you have a need that is:

a) DOCUMENTED

b) EXPLICITLY AUTHORIZED (not Implied)

c) LEGITIMATE

d) DEFINED

When a business need is both “documented” and “defined,” it means that the requirement has been both precisely articulated (defined) and recorded in an official capacity (documented). So a list of people with access is needed for the who, why they legitimately need to access/copy/relocate PAN in terms of their business, explicitly authorized by proper authority (not themselves, obviously).

Finally, let’s talk about technical controls. Now, remember, this applies to REMOTE ACCESS. I’ve heard of clients who says, hey no worries, we have logging and monitoring in place for internal users. Or we have web application firewall in place. Or we have cloudflare in place. Or we have a thermonuclear rocket in place to release in case we get attacked. This control already implies ‘remote access’ into the environment. The users have passed the perimeter. It implies they are already trusted personnel, or contractors or service providers with properly authorized REMOTE ACCESS. Also, note that the authorization here is NOT for remote access, it is for the explicit action of copy/relocating PAN. In this case, most people would probably not have a business reason of copying/relocating PAN to their own systems unless for very specific business flow requirements. This means, only very few people in your organization should have this applied to them, under very specific circumstances. An actual real life example would be for an insurance client we have, they had to copy all transaction information, including card details in an encrypted format and put it into a removable media (like a CD-ROM) and then send it over to the Ombudsman for Financial Services as part of a regulatory requirement. That’s pretty specific.

So what passess off as a ‘technical control’? A Technical control may be as simple as to completely prevent copy/paste or cut/paste ability when accessing via remote access. This can be done in RDP or disable clipboard via SSLVPN. While I am not the most expert product specialist in remote access technologies, I can venture to say its fairly common to have these controls inbuilt into the remote access product. So, there may not be a need for DLP in that sense, as the goal here is to prevent the copying and relocation of PAN.

Now that being said, an umbrella disallow of copy and paste may not go well with some suits or C-levels who want to copy stuff to their drive to work while they are in the Bahamas. Of course. You could provide certain granular controls, depending on your VPN product or which part of the network they access. If a granular control cannot be agreed on, then a possible way is to enforce proper control via DLP (Data Loss Prevention) in endpoint protection. Or control access to CDE/PAN via a hardened jump server that has local policy locked down. So the general VPN into company resources may be more lax, but the moment access to PAN is required, 3.4.2 technical controls come in play.

At the end, how you justify your technical controls could be through a myriad of ways. The importance is of course, cost and efficiency. It has to make cost sense and it must not require your users to jump through hoops like a circus monkey.

So there you have it, a break down of 3.4.2. We are hopping into the next one in the next article so stay tuned. If you have any queries on PCI-DSS v4.0 or other related cybersecurity needs, be it SOC1 or 2, ISO27001, ISO20000, NIST or whether Apollo 11 really landed on the moon in 1969, drop us a note at avantedge@pkfmalaysia.com and we will get back to you!

Introduction to ISO27001 (Information Security Management System)

January 16, 2023 / / 2 Comments

One of our goal for 2023 is to provide more content in our technical articles, not just on PCI-DSS (which we have been primarily writing on), but on other areas where we are focused on. In fact, customers often express a little surprise when we tell them that we also do a lot of consulting on ISO27001, SOC1, SOC2, CSA, ISO2000 and pretty much the main technology compliances, even extending to NIST 800-171 and lesser known standards out there. They primarily associate us with PCI-DSS, which, while it is true it still is our main business, serves as a reminder to them and to us that we often end up forgetting to market our other services.

The other branch where we are very active in is in ISO27001. Like PCI-DSS, we do not do the certification (we leave that to the certifying body), because we often find ourselves helping our customers implement the system itself, and are generally very much involved in building policies, framework and guiding them through the standard.

Before we jump too deep in, let’s wade a bit into the standard for this article.

ISO 27001 is an international standard that outlines the requirements for an information security management system (ISMS). A company can certify to ISO 27001 by implementing the standard and undergoing an audit by a third-party certifying body.

Here are the steps a company can take to certify to ISO 27001:

  1. Understand the standard: Familiarise yourself with the requirements of ISO 27001, including the management system and control objectives.
  2. Perform a gap analysis: Compare your current information security practices to the requirements of the standard to identify any gaps that need to be addressed.
  3. Develop an ISMS: Implement an ISMS that meets the requirements of the standard. This should include policies, procedures, and controls that cover all aspects of information security, including risk management, incident management, and compliance.
  4. Implement the ISMS: Put the ISMS into practice by training employees, updating procedures, and monitoring compliance.
  5. Conduct internal audits: Regularly conduct internal audits to ensure that the ISMS is being effectively implemented and to identify any areas for improvement.
  6. Seek certification: Once the ISMS is fully implemented and operational, seek certification from a third-party certifying body. The certifying body will conduct an audit to ensure that the ISMS meets the requirements of the standard.
  7. Maintain certification: Once certified, it is important to maintain compliance with the standard by regularly reviewing and updating the ISMS, and undergoing periodic surveillance audits.

Certifying to ISO 27001 demonstrates to customers, partners, and regulators that a company is committed to managing and protecting sensitive information, and that it has implemented best practices for information security.

Like all standards, you should go in with your eyes open, as there are several major challenges that companies may face when attempting to certify to ISO 27001, if we were to address it step-by-step in the process described above:

  1. Understanding the standard: The standard is quite comprehensive, and it can be difficult for companies to fully understand all of the requirements and how they apply to their specific organization. The standard doesn’t apply the same for all companies, so beware. It’s not a checklist, either or a cookie cutter standard where you just take lock, stock and two smoking barrels all the requirements and force it down your own throat. There is the risk assessment process, the selection of controls, the statement of applicability – all of which, you can do it on your own or we can help you navigate through the forest of information.
  2. Conducting a gap analysis: Identifying gaps in an organization’s current information security practices can be a challenging task, especially for larger companies with complex systems and processes. Additionally, multiple departments make it more formidable to define scope. Unlike PCI-DSS (which is very definite in terms of scope), the expansion and boundaries of the ISMS can be much less clear.
  3. Implementing an ISMS: Developing and implementing an ISMS that meets the requirements of the standard can be a significant undertaking. It may require significant changes to existing policies and procedures, as well as the implementation of new controls. Expectations, time-resources are often overlooked as well and we have experience where companies go half in and then decide the water is too cold and they back off. It’s always important to set the tone early, set it from the top, which brings us to the next point.
  4. Employee buy-in: Getting employees to understand and buy-in to the importance of information security and to follow the new policies and procedures can be a significant challenge. By far, like any other standard, it’s not really a technical hurdle that often foil a company seeking certification, but human hurdle. People are too busy, or too focused on other areas; they simply do not have time. Without a top-down push, you will find a significant impediment convincing people that this is important. It’s a cliché but it’s true: the project is not an IT project, but a business project.
  5. Cost: Implementing an ISMS and seeking certification can be costly, especially for small and medium-sized businesses. Many a times, potential customers go in with the idea that a budget of RM10k would be enough to go end to end. Now, I am not saying it’s impossible; but it would be very difficult to properly implement an ISMS without a proper budget. The range may vary, true, depending on how much work you can do on your own, but in general, like PCI-DSS, you probably would have to look at a fairly generous budget if this is your first time undertaking ISMS and you do not have an internal team to handle the compliance.
  6. Maintaining compliance: Once certified, it is important to maintain compliance with the standard by regularly reviewing and updating the ISMS, and undergoing periodic surveillance audits. This can be a significant ongoing effort, and it requires dedicated resources to ensure ongoing compliance. The cycle goes through surveillance audit 2 years after the initial certification and re-certification on the third cycle. Survelliance audit is still a fair bit of work as you need to demonstrate compliance to the ISMS standard over the period of the cycle (12 months).
  7. Finding qualified and experienced team: Identifying a qualified and experienced consultants who understand the process and how auditors work can be a big help. Understanding how the auditor conducts a thorough audit and provide valuable feedback on the ISMS can be a challenge, especially for companies that fairly unique in their process or have specific industry requirements.

By understanding these challenges and developing a plan to address them, companies can increase their chances of successfully certifying to ISO 27001. Contact us at avantedge@pkfmalaysia.com for more information on how we can help you begin your ISO27001 journey.

ISO27001 Risk Assessment: Threats vs Vulnerabilities

November 23, 2022 / / 0 Comments

Some of the building blocks in a risk assessment is the identification of threats and vulnerabilities. A lot of times, many people do get mixed up between these two. In the context of ISO27005, a risk is typically defined as the potential that a given threat will exploit the vulnerabilities of an asset or group of assets, causing harm to the organisation. So, understanding both threats and vulnerabilities is crucial to effective risk management.

The above table provides a typical understanding of the difference between these two.

Now, let us provide a few examples of threats and vulnerabilities that you may find useful when you are deriving these for your risk assessment.

a) Database Threats and Vulnerabilities

b) Servers Threats and Vulnerabilities

c) Physical Environment Threats and Vulnerabilities

d) Documentation Threats and Vulnerabilities

e) Application Threats and Vulnerabilities

f) HR (Employee) Threats and Vulnerabilities

The above are samples and examples. There could be many many more different threats, categories and vulnerabilities that are identified in the context of your organisation. If you need any assistance, please let us know and drop us a note at avantedge@pkfmalaysia.com.

Risk Assessments in ISO27005 part 2

September 21, 2022 / / 0 Comments

In part 2 of our dissection of the ISO27005 risk assessment we will have a look at some controls recommended by ISO27005.

Setting the Stage

As usual, in this article series, we’re going to try to do one of our bad anologies to pretend that this isn’t a boring but necessary subject. Imagine you’re a chef preparing a gourmet meal in Nobu Kuala Lumpur. You’ve got your recipe (the ISO27005 standard), your ingredients (your information assets), and your kitchen (your organization). Now, you need to follow the recipe (which is the standard) to turn those ingredients (assets) into a delicious meal (your eventual certification and promotion). That’s where controls come in. They’re the steps you take to protect your information assets and manage your risks. Essentially, why ISO27005 is so attractive to many IT operator is that it is an asset based risk assessment. Let’s run with this chef analogy for this whole article and let’s see if we get hungry by the end of it.

The ISO27005 Control Menu

Now, ISO27005 doesn’t just give you a single recipe to follow. Oh no, it gives you a whole buffet of controls to choose from. It’s like walking into a gourmet restaurant and being handed a menu the size of a phone book. But don’t worry, we’re here to help you navigate this control buffet and pick the right dishes for your organization.

Appetizers: Preventive Controls

Let’s start with the appetizers – preventive controls. These are the controls you put in place to prevent a risk from occurring in the first place. It’s like washing your hands before you start cooking to prevent foodborne illnesses. Wearing a mask so you won’t get infected and so on.

For example, ISO27005 recommends implementing access controls to prevent unauthorized access to your information assets. This could involve things like user authentication (passwords, biometrics, etc.), access restrictions (who can access what), and user account management (creating, updating, and deleting user accounts).

Main Course: Detective Controls

Next up, we have the main course – detective controls. These are the controls you put in place to detect when a risk has occurred. It’s like having a smoke detector in your kitchen to alert you when your gourmet meal has turned into a gourmet disaster.

For instance, ISO27005 recommends implementing monitoring and logging controls to detect security incidents. This could involve things like network monitoring (keeping an eye on your network traffic), log management (collecting and analyzing log data), and intrusion detection systems (detecting unauthorized access attempts). A healthy SOC for instance, goes a long way in detecting issues when or before they occur, which is crucial, especially when events and incidents can happen so quickly. One moment you are settling down for your cup of coffee and the next you are neck deep in phone calls and yelling executives.

Dessert: Corrective Controls

Finally, we have the dessert – corrective controls. These are the controls you put in place to correct a risk that has occurred. It’s like having a fire extinguisher in your kitchen to put out a fire.

For example, ISO27005 recommends implementing incident response controls to respond to security incidents. This could involve things like incident response planning (having a plan in place for responding to incidents), incident response training (training your staff to respond to incidents), and incident recovery (recovering from an incident).

The Anatomy of a Risk Report

That being said, after everything is done and identified and analysed, one still needs to get down to writing the risk report. It doesn’t actually have to be a traditional report, whereby a pdf document, with standard margins, signoffs and such. While this may be the case for many; some organisations are already migrating to system based risk reviews with live dashboards or risks and organisational wide data analytics. With technology growing, there are many tools out there designed to manage risk for you and calculate the ever growing number of vulnerabilities introduced daily. However, if you do find yourself not having these dashboards handy and you need to provide your auditor with something resembling a risk report, here are some guidelines:

The Anatomy of a Risk Report

A risk report isn’t just a list of risks and controls. We have been chucked some pretty cryptic excel sheets that makes as much sense to us as Sanskrit pointing out the Sankara stones locations. As auditors, most of these excel sheets or five page documents may not be enough to pass the litmus test of a risk report. Here’s what a typical risk report might include:

  1. Executive Summary: This is a high-level overview of your risk assessment. It’s like the blurb on the back of a mystery novel, giving the reader a taste of what’s to come. Some throw in graphs or charts here – you never go wrong with a little bit of pictures.
  2. Risk Assessment Methodology: This is a detailed description of how you conducted your risk assessment. This is critical because the auditor will review your risk report based on your risk methodology. If these two does not sync – for instance you have a complex risk calculations in the methodology but in the report, you assess risk by sticking two fingers in your mouth and then holding it up against the cool air … well, that’s a recipe of the famous NC – non compliant.
  3. Risk Analysis: This is where you present your findings. It might be in the form of table, taken from your risk worksheet or excel, or in an asset by asset review; or category by category review. Which ever way , it should be fairly readable, because the audience for this report includes non technical people. So go easy on the jargons.
  4. Risk Treatment Plan: This is your plan of action for dealing with the risks. You should include a list of recommended controls, their expected effectiveness, and their implementation details. This is important. The plan should not just be: OK, we have WAF, that’s cool. And many people get mixed up with the risk treatment plan and the current controls in place. It needs to be clear, whether in the plan, these controls will be implemented, what timeline and by who.
  5. Conclusion and Recommendations: This is where you wrap up your report and make your recommendations. It’s like the detective’s closing argument, convincing the chief that they’ve got the right culprit.

A Sample Risk Analysis, Risk Treatment Plan and Risk Register

Now, let’s take a look at a sample risk analysis and risk treatment plan. Let’s say you’re running an online store, and one of your identified risks is a data breach.

Risk Analysis

  • Risk: Data breach
  • Impact: High (loss of customer trust, potential legal penalties)
  • Likelihood: High (due to lack of strong security measures)
  • Risk Level: High

Risk Treatment Plan

  • Control: Implement stronger security measures, such as encryption and two-factor authentication
  • Expected Effectiveness: High (these measures are proven to reduce the risk of data breaches)
  • Implementation Details: Purchase and install an encryption solution, implement two-factor authentication for all user accounts
  • PIC: Homer Simpson from the Nuclear control room
  • Time Frame: by end of Q4 2022
  • Residual Risk after treatment: 2.4

Risk Register

A typical risk register might include:

  • Risk ID: A unique identifier for each risk (optional for reference)
  • Risk Description: A brief description of the risk.
  • Threats: Threats are external, things that exist that may impact that asset
  • Vulnerabilities: Vulnerabilities are internal, the yin to the Threats’ yang. These are issues that exist within the asset itself.
  • Risk Likelihood: The likelihood of the risk occurring.
  • Risk Impact: The potential impact of the risk.
  • Risk Level/Rating: The overall risk level, based on the impact and likelihood.
  • Control ID: A unique identifier for each control (optional for reference)
  • Control Description: A brief description of the control currently existing
  • Risk Treatment: Implementation of controls to mitigate the risk
  • Risk Monitoring: The expected effectiveness of the control and risk being monitored, or the residual risk remaining

All the above can be monitored within a simple excel sheet, using basic columns and rows. Again, we are not expecting a report written by Leo Tolstoy with a smashing 500 pages to go through, with illustrations and exposition into the answer to the meaning of life, universe and everything. We need something concise, and something that we can go through and something that is implementable in the context of that organisation. That’s it.

If you have futher need for assistance in risk assessments based on ISO27005, drop us a note at avantedge@pkfmalaysia.com and we will get back to you. Happy assessing!

P/S – it’s 42. As in the meaning of life, universe and everything.

Risk Assessments in ISO27005 part 1

August 18, 2022 / / 0 Comments

While most of our writings are in PCI-DSS and we hardly get a whiff of this phenomena called “Risk Assessment”, it’s a different story when it comes to ISO27001 or what we call ISMS or ISO27k. The 27k is a set of guidelines and standards, to which the ISO27001 is the certifiable standard – but there is plenty of cousins, sisters and brothers involved in the 27k family as well…like 73 of them! They are like rabbits! We are specifically looking, in this article at the venerable ISO27005 standard.

While the term risk assessment carries a little gravitas; especially when faced with stony faced board members after a significant breach – to most organisations, they would go – “Risk assessments? Aren’t those just a bunch of fancy words for ‘guessing what could go wrong’?” Well, yes and no. While risk assessments do involve a bit of crystal ball gazing, they’re a lot more structured and methodical, and there are plenty of methodology to go about it. And when it comes to structure and methodology, one that we constantly fall back on (as we are IT compliance practitioners) is this ISO27005.

Setting the Stage

Before we dive headfirst into the nitty-gritty of ISO27005, let’s set the stage a bit. Imagine you’re about to embark on a road trip from KL to Singapore. Oh wait, we don’t have a reason to go to Singapore since the currency is too strong now. Let’s head up to wonderful Penang. You’ve got your snacks, your playlist, and your destination all set. Luggage, hotel booked, sleeping pills for the kids – all set. But before you hit the road, you check the weather, the condition of your car, and maybe even the traffic situation. You check where is every stop where there is a toilet, since children has bladders the size of thimbles. In essence, as simple as it may sound, is a risk assessment in a nutshell. You’re identifying potential issues (risks) that could derail your trip (objective) and taking steps to mitigate them.

Risk Assessment: The ISO27005 Way

Now, let’s translate that to the business world. ISO27005 is like your road trip checklist, but for information security risks. It’s a standard that provides guidelines for information security risk management, or in simpler terms, it’s a roadmap for identifying, assessing, and managing risks to your information assets.

Step 1: Context Establishment

The first step in any risk assessment process is to establish the context. This is like deciding where you’re going on your road trip. In the ISO27005 world, this involves defining the scope and boundaries of your risk assessment. You need to identify what information assets you’re assessing, what the relevant threats and vulnerabilities are, and what the potential impacts could be.

Step 2: Risk Assessment

Once you’ve set the context, it’s time to assess the risks. This is where you identify potential events that could cause harm to your information assets, evaluate the risks associated with these events, and prioritize them based on their potential impact and likelihood.

Let’s say you’re running an online store. One of your information assets could be your customer database. A potential event could be a data breach, the impact could be loss of customer trust and potential legal penalties, and the likelihood could be high if you don’t have strong security measures in place.

Step 3: Risk Treatment

After assessing the risks, the next step is to decide how to treat them. This could involve accepting the risk (if it’s low), avoiding the risk (by not performing the activity that leads to the risk), transferring the risk (to another party), or mitigating the risk (by implementing controls).

In our online store example, you might decide to mitigate the risk of a data breach by implementing stronger security measures, such as encryption and two-factor authentication. Or simply outsource the payment to another PCI-DSS payment gateway thereby transferring part of the risk to them.

Step 4: Risk Acceptance

Once you’ve decided on a treatment, the next step is to accept the risk. This doesn’t mean you’re okay with the risk happening – it just means you’re aware of the risk and have a plan in place to deal with it. The risk after the treatment or controls are what we term as “Residual Risk”. Remember this when faced with stony-faced board members after a significant breach. Say that often.

Step 5: Risk Communication and Consultation

The final step in the ISO27005 process is to communicate and consult with stakeholders about the risk. This could involve informing employees about new security measures, consulting with experts about risk treatment options, or communicating with customers about potential risks.

The ISO27005 Steps

Now, you might be thinking, “That’s all well and good, but where does ISO27005 fit into all this?” Well, think of ISO27005 as the Ten Steps of risk assessments. Except instead of ten, you have a whole lot more. But don’t let that put you off – underneath the jargon, there’s a wealth of wisdom to be found.

Step 1: Identify your Risk!

ISO27005 is big on risk identification. It provides a structured approach to identifying risks, including a comprehensive list of potential threats and vulnerabilities. It’s like a treasure map, but instead of leading to buried gold, it leads to potential risks. Which obviously does not sound as sexy, but you know, risks are….nice, I guess?

Step 2: Analyse your Risk!

Once you’ve identified the risks, ISO27005 guides you through the process of analysing them. This involves evaluating the potential consequences and likelihood of each risk, and assigning a risk level based on these factors. It’s like a crystal ball, helping you see into the future of what could go wrong.

Step 3: Evaluate your Risk!

After analyzing the risks, ISO27005 helps you evaluate them. This involves comparing the risk levels against your risk criteria to determine which risks need to be treated. It’s like a sorting hat, but for risks. This is by far, one of the trickiest to manage and this is where a good risk manager gets paid to do the work. Because in a risk workshop, every stakeholder or process owner will say their risks are highest. Yes, the facilities guy is going to state that the HVAC malfunction will cause the end of the world. Yes, the IT head is going to say that the next breach due to a lack of WAF and SOAR components will bring upon the extermination of the multiverse. And even the guy in charge of the cleaning lady is going to state that if his risk is not looked into, the cleaning lady will likely be an MI6 operative who is sent to assassinate the entire board of directors. So risk manager, do your job!

Step 4: Treat Your Risk!

When it comes to risk treatment, ISO27005 offers a range of options. You can avoid the risk, take on the risk and its potential consequences, share the risk with another party, or implement controls to mitigate the risk. It’s like a choose-your-own-adventure book, but with less adventure and more risk mitigation. It is as bland as it sounds, but hey, do what you gotta do. How many times we have seen risk assessments carried out without any treatment plan? More than we can count. A lot of organisations simply think that identifying risks are good enough, and then accepts every single risk there is. So their risk treatment plan is ACCEPT everything.

Step 5: Monitor and Review Your Risk!

Finally, ISO27005 emphasizes the importance of ongoing risk monitoring and review. This involves keeping an eye on your risks, reviewing your risk assessments, and updating your risk treatments as necessary. It’s like a car’s rear-view mirror, helping you keep an eye on what’s behind you while you focus on the road ahead. A dashboard of risk will help on this, or for the more primitive, a slew of excel sheets can also be used. Whichever way, it needs to be communicated to the risk committee and be able to be updated and reviewed regularly.

Bringing It All Together

So, there you have it – an introduction into the world of ISO27005 risk assessments. It might seem a bit daunting at first, but once you get the hang of it, it’s a powerful tool for managing your information security risks.

Just remember – risk assessments aren’t a one-and-done deal. They’re an ongoing process that needs to be revisited regularly. So, keep your ISO27005 roadmap handy, and don’t be afraid to take a detour or two along the way.

And remember, if you ever feel lost in the wilderness of risk assessments, don’t hesitate to reach out for help. Whether it’s a question about ISO27005, a query about risk treatment options, or ISO in general, drop us a note at avantedge@pkfmalaysia.com and we’ll get back to you.

In the next article, we’ll take a closer look at some of the specific controls recommended by ISO27005, templates that may help you get started, and how they can help you mitigate your information security risks. Until then, happy risk assessing!

« Older posts

© 2024 PKF AvantEdge

— Up ↑