You should log in to our Customer Portal https://epps.c************** where you will see all the videos. You have received login information through email when you purchased the product from us.
BIA & RA Review Period
Neither ISO 27001 nor ISO 22301 do not prescribe how often the risk assessment and business impact analysis must be reviewed.
However, once a year really is the best practice because of the following:
2) If you perform reviews less often, then you are in a danger that your RA / BIA will become too outdated because the pace of change (especially in IT) is really quick.
ISMS Scope Question
This depends where is your most valuable information located - if it is located in HR/Finance departments, then they should be included in the ISMS scope; also if you are a smaller company it would be difficult to exclude such departments from the scope even though the information is not located there.
The main issue in business continuity is timing, or to be more precise the recovery time objective (RTO). If the RTO is couple of hours, you will be able to retrieve your EMS from the backup file; if RTO is couple of minutes you won't be able to do it from backup, which means you will need to have something more than the backup.
Both of these categories are your suppliers. However, not both of them are equally risky for your company - therefore, after you perform your risk assessment you will realize that your stationery does not pose threat to your information, while consultancy could - this means that you will have to perform certain controls on your consultant only.
The point is - you do not divide the suppliers upfront based on their business. You should decide whether to apply security controls only after you perform risk assessment, no matter what they do.
To calculate the risk, you have to assess two main components: impact and likelihood. In most cases the scales for those two components are the same (e.g. low-medium-high for both, or 1 to 5 for both).
However, if you assess business continuity risks, you can add additional weight to high impact if you feel this will better represent the resulting risk - in other words, you are free to set you risk assessment methodology as you see fit.
Regarding the acceptable level of risk, it is set for the risk itself, not separately for the components (impact and likelihood).
Answer: Information and communication technology should serve the business part of the organization, therefore a person who is in charge of business continuity should set the rules for risk assessment and for continuity / disaster planning for all departments in a company, including the IT department.
ISMS for scratch card manufacturing unit
ISO 27001 is not prescriptive, which means that this standard doesn't tell you which controls you must or must not apply depending on the industry you're in. What this standard does tell you is that you must assess the risks that are related to your particular situation, and then decide which controls to implement and which to exclude. See also this article: The basic logic of ISO 27001: How does information security work? https://advisera.com/27001academy/knowledgebase/the-basic-logic-of-iso-27001-how-does-information-security-work/
Therefore, ISO 27001 is quite different from PCI DSS which is prescriptive. If your business is related to payment card industry, then PCI DSS will provide much more precise guidelines for security controls.
Logs management
In a company in the policy they have mentioned log management. but in practice there is no log management system.
At webinar you gave answer as in the server all will be recording. But what is the problem in the organisation there is no server.
Only workstations 160 systems function as workgroup only.
Each and every system it contains logs . what to do in this situation. is it a nc .if nc is it a major or minor.
Their core business is SDLC, and BPO there also no logs.
Answer:
The key question here is : Do need logs at all? Your risk management process will give you the answer. This article can help you:
However, logs are an essential way to register what happens so that you can come back on them when needed. Centralising the logs makes it easier to read and analyse them without impacting on the operations.
Analysing logs require to accessing them first and requires time, and expertise to understand their coding and to discover the trends thats the data hide. Most of the time using a specific tool is he lpful. Doing it with a server allows you 1) to gather all logs on one single place, 2) use one single tool and 3) use the server time and not the work station time, even if the analysis can be done in backlog (outside the work time, and potentially detecting issues to late so you arent able to react adequately) or as a backstage application. You then gain time and the cost of the analysis tools.
All the controls for development , maintenance , support
Afef,
This is primarily the question of setting the ISMS scope. If your scope covers only the systems you develop and maintain internally, then the controls from Annex A have to apply only to those systems; if you include in your scope also the products you deliver to your customers, then the controls must cover them as well.
If you include in the scope the products you deliver to your customers, then you have to assess all the risks related to information contained in those products, and then you have to apply applicable controls.