Moved a directory, changed some filenames
This commit is contained in:
parent
ae27a60bcf
commit
347706835e
195 changed files with 696 additions and 255 deletions
|
|
@ -0,0 +1,8 @@
|
|||
# About A-5.33: Protection of records
|
||||
|
||||
This Control is about the **control, purpose, and guidance for managing and protecting organizational records** to ensure their authenticity, integrity, availability, and compliance with various requirements over time.
|
||||
|
||||
I would say: record keeping procedures, in line with legal and other requirements.
|
||||
|
||||
[Original Text](../ISO-27002-OST/ISO27002-EN-2022/a-5.33-Protection-of-records.md)
|
||||
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
# About Control 8.3: Information access restriction
|
||||
|
||||
Restricting access to information assets in line with the access control policy.
|
||||
|
||||
Control 8.3 operationalizes the foundational rules set in [A5.15](../ISO-27002-OST/ISO27002-EN-2022/a-5.15-Access-control.md) by implementing detailed technical measures.
|
||||
|
||||
[Original Text](../ISO-27002-OST/ISO27002-EN-2022/a-8.3-Information-access-restriction.md)
|
||||
|
||||
|
||||
|
||||
12
Corpus/Standards/ISO27x/about/Authentication.md
Normal file
12
Corpus/Standards/ISO27x/about/Authentication.md
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
# Authentication
|
||||
Authentication is the proof of identity that is achieved through providing credentials to the access control mechanism.
|
||||
|
||||
|
||||
|
||||
See also:
|
||||
- [a-8.5-Secure-authentication](../OST/27002/EN/a-8.5-Secure-authentication.md)
|
||||
- [Authentication Methods Used for Network Security](../../../Information%20Security/Authentication%20Methods%20Used%20for%20Network%20Security.md)
|
||||
- [Identity and Access Management (IAM)](../../../Information%20Security/Identity%20and%20Access%20Management%20(IAM).md)
|
||||
- [Authorization](Authorization.md)
|
||||
- [Identification](../../../Information%20Security/Identification.md)
|
||||
|
||||
13
Corpus/Standards/ISO27x/about/Authorization.md
Normal file
13
Corpus/Standards/ISO27x/about/Authorization.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
# Authorization
|
||||
Authorization is the mechanism that determines the access level(s) of the subjects to the objects.
|
||||
|
||||
See also:
|
||||
- [Authorization vs Access Control](../../../ISMS/Authorization%20vs%20Access%20Control.md)
|
||||
- [Access Control Models](../../../ISMS/Access%20Control%20Models.md)
|
||||
- [Authentication](Authentication.md)
|
||||
- [Identification](../../../Information%20Security/Identification.md)
|
||||
- [CASSM Consumer Authentication Strength Maturity Model](../../../Information%20Security/CASSM%20Consumer%20Authentication%20Strength%20Maturity%20Model.md)
|
||||
- [Identity and Access Management (IAM)](../../../Information%20Security/Identity%20and%20Access%20Management%20(IAM).md)
|
||||
- [a-5.15-Access-control](../OST/27002/EN/a-5.15-Access-control.md) ???
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
# Change Management in ISO 27002
|
||||
|
||||
Change Management in ISO 27002:
|
||||
- [5.8:](../Standards/MoCs/ISO_27002_2022_5.8_MoC%20Information%20security%20in%20project%20management.md) Information security in project management
|
||||
- [5.22:](../Standards/MoCs/ISO_27002_2022_5.22_MoC%20Monitoring,%20review%20and%20change%20management%20of%20supplier%20services.md) Monitoring, review and change management of supplier services
|
||||
- [8.28:](../Standards/MoCs/ISO_27002_2022_8.28_MoC%20Secure%20coding.md) Secure coding
|
||||
- [8.29:](../Standards/MoCs/ISO_27002_2022_8.29_MoC%20Security%20testing%20in%20development%20and%20acceptance.md) Security testing in development and acceptance
|
||||
- [8.32:](../Standards/MoCs/ISO_27002_2022_8.32_MoC%20Change%20management.md) Change management
|
||||
|
||||
Also check the topic of risk / impact assessment.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 115 KiB |
|
|
@ -0,0 +1,43 @@
|
|||
Based on the text of **ISO/IEC 27001:2022**, the standard explicitly identifies specific roles and categories of individuals with distinct responsibilities regarding the Information Security Management System (ISMS).
|
||||
|
||||
These roles are categorized below by their function within the standard:
|
||||
|
||||
### 1. Top Management
|
||||
|
||||
"Top management" is the most prominent role cited throughout the standard. They are responsible for:
|
||||
|
||||
- Overall leadership w/r/t information security and commitment to the ISMS.
|
||||
- Establishing the information security policy and objectives.
|
||||
- Ensuring necessary resources are available for the ISMS.
|
||||
- Ensuring responsibilities and authorities for relevant roles are assigned and communicated.
|
||||
- Conducting management reviews of the ISMS at planned intervals.
|
||||
|
||||
### 2. Risk Owners
|
||||
|
||||
Risk owners (explicitly required by the standard) are identified in the risk management process (C.6.1.2). They must **approve the risk treatment plan** and **accept the residual risk** that remains after treatment.
|
||||
### 3. Auditors
|
||||
|
||||
In the context of performance evaluation, the standard refers to **auditors**. The organization is required to select auditors to conduct internal audits ensuring objectivity and impartiality.
|
||||
|
||||
### 4. Asset Owners
|
||||
|
||||
While the main body of the standard focuses on _risk_ owners, **Annex A** (which lists the information security controls) explicitly mentions **owners** in the context of assets.
|
||||
|
||||
- **Control 5.9 (Inventory of information and other associated assets):** Requires an inventory of assets to be developed and maintained, "including **owners**".
|
||||
|
||||
### 5. Personnel and Persons Doing Work
|
||||
|
||||
The standard refers to the broader workforce under two main categories:
|
||||
|
||||
- **Persons doing work under the organization's control:** The organization must determine the necessary competence of these persons and ensure they are aware of the information security policy and their contribution to the ISMS.
|
||||
- **Personnel:** Within Annex A, controls explicitly refer to "personnel" regarding screening, terms of employment, disciplinary processes, and information security awareness.
|
||||
|
||||
### 6. Other Relevant Management Roles
|
||||
|
||||
Clause 5.1 mentions that Top Management must support "other relevant management roles" to demonstrate their leadership as it applies to their specific areas of responsibility.
|
||||
|
||||
### 7. Interested Parties
|
||||
|
||||
While not an internal "role" in the traditional sense, the standard explicitly requires the organization to determine relevant **interested parties** (stakeholders) and their requirements, which must be addressed by the ISMS.
|
||||
|
||||
**Note on Specific Job Titles:** ISO 27001 describes responsibilities (e.g., "reporting on the performance of the information security management system") but generally does not prescribe specific job titles like "CISO" or "Security Manager." Instead, it requires Top Management to assign the _responsibility and authority_ for these tasks.
|
||||
BIN
Corpus/Standards/ISO27x/about/FAIR ISO 27005 Cookbook.pdf
Normal file
BIN
Corpus/Standards/ISO27x/about/FAIR ISO 27005 Cookbook.pdf
Normal file
Binary file not shown.
|
|
@ -0,0 +1,207 @@
|
|||
# Governance model for the ISMS, it's Policies and Controls
|
||||
|
||||
Based on ISO 27001 and ISO 27002, a governance model for your ISMS should be structured around **Top Management's accountability** while delegating the **tactical execution** to specific information security roles.
|
||||
|
||||
*See [Basic ISMS governance model](../../../ISMS/Basic%20ISMS%20governance%20model.md) for a compacted version*
|
||||
## Related to the Policies Lifecycle
|
||||
|
||||
Here is a suggested governance model mapping the lifecycle of security policies (commissioning, drafting, approving, etc.) to the specific roles mandated by the standards.
|
||||
### **1. Top Management**
|
||||
|
||||
**Primary Mandate:** _Commissioning, Approving, and Signing Off._
|
||||
|
||||
In the ISO 27001 framework, Top Management holds the ultimate accountability. They do not necessarily write the policies, but they must authorize them to ensure they align with business strategy.
|
||||
|
||||
- **Commissioning:** Top management must ensure the information security policy is established and compatible with the strategic direction of the organization.
|
||||
- **Signing Off / Approving:** They must formally approve the information security policy. Any changes to the high-level policy must also be approved by them.
|
||||
- **Resourcing:** They are responsible for ensuring the resources needed for the ISMS are available.
|
||||
|
||||
– see [C.5.1](../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), [A.5.1](../legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md)
|
||||
### **2. Information Security Manager / Competent Personnel**
|
||||
|
||||
**Primary Mandate:** _Drafting, Advising, and Reviewing._
|
||||
|
||||
This role (often assigned to a CISO, Security Manager, or a specialized committee) functions as the architect of the system.
|
||||
|
||||
- **Drafting:** The development of policies should be allocated to personnel with the appropriate technical competency. They draft the "Information Security Policy" (high-level) and "Topic-Specific Policies" (e.g., Access Control, Backup).
|
||||
- **Advising / Consulting:** This role provides subject matter expertise. They may seek advice from external subject matter experts or special interest groups to ensure policies match best practices and current threats.
|
||||
- **Reviewing:** They must review policies at planned intervals or when significant changes occur (e.g., new technologies, new risks) to ensure continued suitability.
|
||||
|
||||
### **3. Line Management / Function Owners**
|
||||
|
||||
**Primary Mandate:** _Consulting and Enforcing._
|
||||
|
||||
Managers throughout the organization (HR, IT, Operations) act as the bridge between the policy and the employees.
|
||||
|
||||
- **Consulting:** While the security team drafts policies, line managers should be consulted to ensure the policies are practical and do not conflict with operational efficiency.
|
||||
- **Enforcing:** Management requires all personnel to apply information security in accordance with the established policies. They are responsible for ensuring their teams are properly briefed on these roles. – see [A.5.4](../../MoCs/ISO_27002_2022_5.4_MoC%20Management%20responsibilities.md)
|
||||
|
||||
### **4. All Personnel and Interested Parties**
|
||||
|
||||
**Primary Mandate:** _Acknowledging and Adhering._
|
||||
|
||||
- **Acknowledging:** Once a policy is published and communicated, recipients (employees and relevant external parties) should be required to acknowledge they understand and agree to comply.
|
||||
- **Adhering:** Personnel must apply the policies in their daily work. – see [A.5.4](../../MoCs/ISO_27002_2022_5.4_MoC%20Management%20responsibilities.md)
|
||||
|
||||
---
|
||||
|
||||
### **Governance Workflow: The Policy Lifecycle**
|
||||
|
||||
To operationalize this model, you can organize your governance activities into the following lifecycle stages, as supported by ISO 27002:
|
||||
|
||||
| Governance Activity | Responsible Role |
|
||||
| :------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **1. Commissioning** | **Top Management** directs that a policy be created to address business needs, risks, or regulations. |
|
||||
| **2. Drafting** | **Security Manager/Specialist** writes the content. This includes creating _Topic-Specific Policies_ (e.g., Access Control, Clear Desk). |
|
||||
| **3. Consulting** | **Subject Matter Experts** (Legal, HR, IT) review the draft to ensure technical feasibility and legal compliance. |
|
||||
| **4. Approving** | **Top Management** formally signs off. For lower-level _Topic-Specific Policies_, approval may be delegated to an appropriate level of management (e.g., IT Director approving the Backup Policy). |
|
||||
| **5. Communicating** | **Security Manager/HR** publishes the policy in a format accessible to all employees and relevant external parties. |
|
||||
| **6. Acknowledging** | **All Personnel** sign or digitally acknowledge that they have read and understood the policy. |
|
||||
| **7. Reviewing** | **Security Manager** re-evaluates the policy at planned intervals or after significant changes (e.g., a security incident). |
|
||||
These can be deducted from [C.5.1](../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), [A.5.1](../legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md), C.0.1, and C.0.2
|
||||
|
||||
### **Analogy: The Legislative Process**
|
||||
|
||||
To visualize this governance model, consider the passing of a **Law (Policy)** in a city:
|
||||
|
||||
- **Top Management is the City Council/Mayor:** They commission the law ("We need a law to stop speeding") and give the final signature to make it valid (**Approving**). They don't usually write the legal text themselves.
|
||||
- **The Security Manager is the Drafting Committee/Legal Counsel:** They research traffic data, write the specific legal text, and ensure it doesn't contradict existing laws (**Drafting/Advising**).
|
||||
- **Line Managers are the District Captains:** They make sure their specific precincts know about the new law and enforce it (**Enforcing**).
|
||||
- **Employees are the Citizens:** They must read the notification of the new law and drive within the speed limit (**Acknowledging/Adhering**).
|
||||
|
||||
## Roles and Responsibilities mentioned in ISO 27001
|
||||
|
||||
Based on ISO 27001 and the supporting guidance in ISO 27002 and ISO 27000, the standards identify several distinct ownership and management roles necessary for the effective governance of information security.
|
||||
|
||||
These roles are categorized into high-level governance, specific ownership accountabilities, and operational responsibilities.
|
||||
|
||||
### **1. Top Management**
|
||||
|
||||
Top management is defined as the person or group of people who directs and controls the organization at the highest level. They hold the ultimate accountability for the ISMS.
|
||||
|
||||
- **Responsibilities:** They are responsible for establishing the information security policy, ensuring it is compatible with the strategic direction of the organization, and ensuring necessary resources are available.
|
||||
- **Delegation:** Top management must ensure that responsibilities and authorities for roles relevant to information security are assigned and communicated within the organization.
|
||||
- **Review:** They must review the organization's ISMS at planned intervals to ensure its continuing suitability, adequacy, and effectiveness.
|
||||
|
||||
(More on Leadership Responsibilities [here](ISO%2027001%20Leadership%20Responsibilities.md)).
|
||||
### **2. Ownership Roles**
|
||||
|
||||
The standards distinguish between general management and "ownership," which implies specific accountability for risks and assets.
|
||||
|
||||
**A. Risk Owners**
|
||||
|
||||
- **Definition:** A risk owner is a person or entity with the accountability and authority to manage a specific risk.
|
||||
- **Key Mandate:** ISO 27001 explicitly requires the organization to identify risk owners during the risk assessment process.
|
||||
- **Authority:** Risk owners are responsible for approving the information security risk treatment plan and accepting any residual information security risks.
|
||||
|
||||
**B. Asset Owners**
|
||||
|
||||
- **Definition:** While not strictly defined in the vocabulary standard (ISO 27000), ISO 27002 requires that an inventory of assets be maintained and that "ownership" of these assets be assigned to an individual or group.
|
||||
- **Responsibilities:** The asset owner is responsible for the proper management of an asset over its entire lifecycle. Specific duties include:
|
||||
- Ensuring assets are inventoried and classified.
|
||||
- Establishing requirements for acceptable use.
|
||||
- Reviewing access restrictions and classifications periodically.
|
||||
- Authorizing proper disposal or deletion of data.
|
||||
- **Delegation:** Asset owners may delegate daily tasks (e.g., to a custodian looking after the asset), but the owner remains accountable for the asset's protection.
|
||||
|
||||
### **3. Operational and Specific Security Roles**
|
||||
|
||||
While ISO 27001 allows organizations to define roles based on their needs, the standards specifically reference or imply the following functional roles:
|
||||
|
||||
- **Information Security Management Function:** ISO 27001 requires the assignment of responsibility for ensuring the ISMS conforms to requirements and for reporting on its performance to top management. In practice, this is often the Information Security Manager or CISO.
|
||||
- **Privacy Officer:** ISO 27002 suggests that compliance with privacy regulations is often best achieved by appointing a responsible person, such as a privacy officer, to provide guidance to personnel.
|
||||
- **Project Management / Steering Committee:** ISO 27002 advises that information security should be integrated into project management, with follow-ups performed by governance bodies such as a project steering committee.
|
||||
- **Auditors:** ISO 27001 mandates internal audits, requiring the selection of auditors who can ensure objectivity and the impartiality of the audit process.
|
||||
- **System Administrators / Privileged Users:** ISO 27002 highlights the need to identify and manage users with "privileged access rights" (e.g., system administrators) who can override system or application controls.
|
||||
|
||||
### **Summary of Accountability vs. Responsibility**
|
||||
|
||||
To apply this to your governance model:
|
||||
|
||||
- **Top Management** provides the **mandate** and resources.
|
||||
- **Risk Owners** provide the **authorization** for how risks are handled.
|
||||
- **Asset Owners** define the **protection requirements** for the data they own.
|
||||
- **Security Roles/Personnel** execute the **controls** and day-to-day operations.
|
||||
|
||||
## Roles and Responsibilities regarding Controls
|
||||
|
||||
Based on ISO 27001 and ISO 27002, the roles and responsibilities regarding the lifecycle of controls (implementing, monitoring, establishing effectiveness, and evaluating) are distributed across several levels of the organization.
|
||||
|
||||
The standards define these responsibilities as follows:
|
||||
|
||||
### **1. Top Management**
|
||||
|
||||
Top management holds the ultimate accountability for the system's success but delegates specific tasks.
|
||||
|
||||
- **Implementing:** They must ensure that the resources needed for the ISMS (and by extension, the controls) are available and that ISMS requirements are integrated into the organization’s processes. – see [C.5.1](../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md)
|
||||
- **Monitoring & Effectiveness:** They must assign responsibilities for reporting on the performance of the ISMS. – see [C.5.3](../../MoCs/ISO_27001_2022_5.3_MoC%20Organizational%20roles,%20responsibilities%20and%20authorities.md)
|
||||
- **Evaluating:** They are required to review the ISMS at planned intervals (Management Review) to ensure its continuing suitability, adequacy, and effectiveness. – see [C.9.2.2](../../MoCs/ISO_27001_2022_9.2_MoC%20Internal%20audit.md), [C.9.3.1](../../MoCs/ISO_27001_2022_9.3_MoC%20Management%20review.md)
|
||||
### **2. Risk Owners**
|
||||
|
||||
Risk owners are central to the decision-making process regarding which controls are applied.
|
||||
|
||||
- **Implementing:** They are responsible for approving the information security risk treatment plan. This effectively means they authorize the implementation of the controls selected to modify risks.
|
||||
- **Establishing Effectiveness:** They must accept any residual information security risks that remain after controls have been implemented.
|
||||
|
||||
– see [C.6.1.3](../../MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md) and Note 2 for 3.62 risk acceptance.
|
||||
### **3. Asset Owners**
|
||||
|
||||
ISO 27002 places significant operational responsibility on the owners of assets.
|
||||
|
||||
- **Implementing:** They are responsible for the proper management of an asset over its entire life cycle. This includes ensuring assets are properly classified and protected.
|
||||
- **Monitoring:** They must review access restrictions and classifications periodically to ensure they remain effective.
|
||||
|
||||
– see [A.5.9](../../MoCs/ISO_27002_2022_5.9_MoC%20Inventory%20of%20information%20and%20other%20associated%20assets.md)
|
||||
### **4. Managers (Line Management)**
|
||||
|
||||
Managers play a critical role in enforcing controls within their specific areas of operation.
|
||||
|
||||
- **Implementing:** Management should require all personnel to apply information security in accordance with established policies and procedures. They are responsible for ensuring personnel are properly briefed on their roles prior to being granted access to information.
|
||||
- **Monitoring & Effectiveness:** Managers should regularly identify and review whether information security requirements are being met within their area of responsibility. If non-compliance is found, managers must identify causes, evaluate the need for corrective action, and implement it.
|
||||
|
||||
– see [A.5.4](../../MoCs/ISO_27002_2022_5.4_MoC%20Management%20responsibilities.md), [A.5.5](../../MoCs/ISO_27002_2022_5.5_MoC%20Contact%20with%20authorities.md), [A.5.6](../../MoCs/ISO_27002_2022_5.6_MoC%20Contact%20with%20special%20interest%20groups.md), [A.5.36](../../MoCs/ISO_27002_2022_5.36_MoC%20Compliance%20with%20policies,%20rules%20and%20standards%20for%20information%20security.md)
|
||||
### **5. Information Security Management Function**
|
||||
|
||||
While individual managers implement controls, a specific security function (often an Information Security Manager) provides oversight and specialized support.
|
||||
|
||||
- **Implementing:** This role often takes overall responsibility for the development and implementation of information security, supporting the identification of risks and mitigating controls.
|
||||
- **Monitoring:** They may assist in monitoring activities, such as reviewing logs or managing vulnerability processes,.
|
||||
|
||||
– see [A.5.2](../../MoCs/ISO_27002_2022_5.2_MoC%20Information%20security%20roles%20and%20responsibilities.md), [A.8.8](../../MoCs/ISO_27002_2022_8.8_MoC%20Management%20of%20technical%20vulnerabilities.md)
|
||||
### **6. Internal Auditors and Independent Reviewers**
|
||||
|
||||
These roles are strictly focused on evaluation and verification.
|
||||
|
||||
- **Evaluating:** The organization must conduct internal audits to provide information on whether the ISMS conforms to requirements and is effectively implemented and maintained,.
|
||||
- **Effectiveness:** An independent review (by internal audit or external party) assesses the organization's approach to managing information security and its implementation to ensure continuing suitability and effectiveness,.
|
||||
|
||||
– see [C.9.2.1, C.9.2.2](../../MoCs/ISO_27001_2022_9.2_MoC%20Internal%20audit.md), [A.5.35](../../MoCs/ISO_27002_2022_5.35_MoC%20Independent%20review%20of%20information%20security.md)
|
||||
|
||||
### **7. All Personnel**
|
||||
|
||||
- **Implementing:** All employees are required to apply information security in accordance with established policies and procedures.
|
||||
- **Monitoring:** They contribute to monitoring by reporting observed or suspected information security events (e.g., ineffective controls, human errors, or non-compliance) through established channels,.
|
||||
|
||||
– see [A.5.4](../../MoCs/ISO_27002_2022_5.4_MoC%20Management%20responsibilities.md), [A.5.5](../../MoCs/ISO_27002_2022_5.5_MoC%20Contact%20with%20authorities.md), [A.5.6](../../MoCs/ISO_27002_2022_5.6_MoC%20Contact%20with%20special%20interest%20groups.md), [A.6.8](../../MoCs/ISO_27002_2022_6.8_MoC%20Information%20security%20event%20reporting.md)
|
||||
|
||||
---
|
||||
|
||||
### **Summary Table of Responsibilities**
|
||||
|
||||
|Role|Implementation|Monitoring & Effectiveness|Evaluation|
|
||||
|:--|:--|:--|:--|
|
||||
|**Top Management**|Provides resources and mandate.|Reviews performance reports.|Conducts Management Review.|
|
||||
|**Risk Owner**|Approves the risk treatment plan.|Accepts residual risk.|Reviews risk status.|
|
||||
|**Asset Owner**|Ensures proper protection of assets.|Periodically reviews access and classification.|Verifies asset inventory accuracy.|
|
||||
|**Line Manager**|Enforces policies with staff.|regular reviews of compliance; initiates corrective action.|Reports review results to independent reviewers.|
|
||||
|**Internal Auditor**|N/A (Must remain independent).|N/A|Tests conformity and effectiveness.|
|
||||
|
||||
### **Analogy: The City Infrastructure**
|
||||
|
||||
To visualize these roles regarding **controls** (e.g., traffic lights and speed bumps):
|
||||
|
||||
- **Top Management (City Council):** Allocates the budget for road safety and reviews annual safety reports to see if the city is safer (**Evaluation**).
|
||||
- **Risk Owner (City Planner):** Decides that a specific intersection is dangerous and authorizes the installation of traffic lights (**Implementing/Approving Treatment**).
|
||||
- **Asset Owner (Road Maintenance Chief):** Ensures the traffic lights are actually installed, cataloged, and working correctly on a daily basis (**Implementing/Monitoring**).
|
||||
- **Line Manager (Precinct Captain):** Ensures their officers are enforcing traffic laws and that the officers themselves obey speed limits (**Monitoring Compliance**).
|
||||
- **Internal Auditor (Inspector General):** Independently checks if the traffic lights meet legal codes and if the police are actually issuing tickets as reported, without fixing the lights themselves (**Evaluating**).
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
# ISO 17021 Conformity assessment
|
||||
|
||||
Certification of management systems is a third-party conformity assessment activity and bodies performing this activity are therefore third-party conformity assessment bodies.
|
||||
|
||||
See [Clause 10.1](https://www.isms.online/iso-27001/10-1-nonconformity-and-corrective-action/))
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
|
||||
|
||||
|
||||
## Steps
|
||||
|
||||
The steps for conducting an initial Business Impact Analysis (BIA) are:
|
||||
|
||||
- **Define the context and scope of the BIA process.** This involves understanding the organization’s external and internal operating environments, including its business processes, activities, and resources. The BIA process should cover the entire scope of the business continuity management system (BCMS), which should be defined in terms of the organization’s products and services.
|
||||
|
||||
- **Define and communicate roles and responsibilities for the BIA process.** Top management should ensure that roles and authorities are assigned, communicated, and that resources are provided. Key roles include the BIA leader and activity owners. The **BIA leader is responsible for the BIA process**, including preparing and delivering the BIA methodology, planning, and managing the process, consolidating and analyzing information, and presenting the outcomes to top management. **Activity owners are responsible for providing a detailed understanding of their activities, applying the BIA methodology, and providing information to the BIA leader**.
|
||||
|
||||
- **Obtain commitment from leadership and allocate adequate resources.** Top management commitment is essential for the BIA process. This includes communicating the value of the BIA process, providing support, allocating sufficient resources, agreeing on methods, priorities, and time frames, and ensuring an environment of continual improvement.
|
||||
|
||||
- **Plan the BIA.** This can include allocating resources, grouping products and services with similar characteristics, identifying the organizational structure and teams or individuals that can provide information, and communicating expectations to participants.
|
||||
|
||||
- **Agree on the approach for undertaking the BIA process.** This involves understanding the potential impacts of a disruption on the organization. Impacts can include loss of revenue, market share, customer confidence, reputation, and legal or regulatory penalties.
|
||||
|
||||
- **Define impact types and criteria.** The organization should define impact types and criteria to understand the impact of a disruption over time. Impact types can include business objectives, environmental, financial, health and safety, legal, regulatory, contractual, market share, operational, and reputational. Criteria should be defined for each impact type to determine when the impact becomes unacceptable. This can be done by defining thresholds or using an impact matrix.
|
||||
|
||||
- **Define time frames.** Impacts typically increase over time, so it’s important to define time frames to assess the magnitude of the impact. This can be done using a set number of time frames or a set number of time frames within which to consider the increasing impact.
|
||||
|
||||
- **Define the BIA methodology.** A consistent methodology should be defined to assess all products, services, and activities. The methodology should include how to assess impacts over time, the definition of the maximum tolerable period of disruption (MTPD), and the recovery time objective (RTO).
|
||||
|
||||
- **Determine the priorities of products and services with top management.** Top management should determine the priorities of products and services based on the organization’s objectives, obligations, and the potential impacts of a disruption. Factors to consider include legal and regulatory requirements, contractual obligations, customer expectations, and the impact of failure to deliver. The output should be a list of prioritized products and services and their continuity requirements.
|
||||
|
||||
- **Determine the prioritized activities.** For each prioritized product and service, the related activities should be identified. Activity owners should then assess the impacts of a disruption over time, identify the MTPD, and set the RTO for each activity. The output should be a list of prioritized activities and their RTOs.
|
||||
|
||||
- **Identify resources and other dependencies.** The resources and dependencies required to perform prioritized activities should be identified. These can include people, information and data, physical infrastructure, equipment, ICT systems, transportation and logistics, finances, partners, and suppliers. For each resource, the quantity, time frame, characteristics, dependencies, and applicable requirements should be documented.
|
||||
|
||||
- **Analyze and consolidate BIA results.** The information gathered from all levels of the BIA process should be analyzed and consolidated to identify business continuity priorities and requirements. The organization should choose an appropriate analytical approach, ensuring the information is correct, credible, consistent, current, and complete.
|
||||
|
||||
- **Obtain top management approval for BIA results.** The BIA leader should present the BIA results to top management for their review, amendment, and approval. This should include the prioritization of products and services, activities, and resources. Top management approval should be documented. The BIA results can then be used to identify and select business continuity strategies and solutions.
|
||||
|
||||
- **Review the BIA process and methodology.** The BIA process and methodology should be reviewed regularly and updated as needed to ensure its effectiveness and efficiency.
|
||||
|
||||
- **Review BIA results.** The BIA results should be reviewed periodically and whenever there are significant changes within the organization or its context that could affect the business continuity priorities and requirements.
|
||||
|
||||
|
||||
## Dependencies between processes and assets
|
||||
|
||||
The ISO/TS 22317:2021(E) standard emphasizes the importance of understanding dependencies between processes and assets in conducting a Business Impact Analysis (BIA). This involves recognizing how disruptions to one area can affect others, both internally and externally.
|
||||
|
||||
Here's what the standard highlights:
|
||||
|
||||
- **Impact of Disruptions on the delivery of products and services**
|
||||
The BIA process should consider how disruptions can affect the delivery of products and services to customers and other interested parties.This includes disruptions originating internally, within the supply chain, or from external sources. The analysis should consider how these disruptions can impact various stakeholders, including customers, partners, the community, media, shareholders, creditors, competitors, staff, and regulators.
|
||||
- **Interdependencies of Activities**
|
||||
When analyzing the impact of disruptions on specific activities, it is crucial to consider their interdependencies on other activities, both within and outside the organization. This means understanding how a disruption to one activity can affect the ability of other activities to function. For instance, a delay in a manufacturing process could impact subsequent production stages or even the final delivery of a product.
|
||||
- **Resource Dependencies**
|
||||
A detailed understanding of daily resource requirements is essential to identify the resources necessary to recover or maintain prioritized activities following a disruption. These resources can include various assets like:
|
||||
- People (staff, contractors)
|
||||
- Information and data (including vital records)
|
||||
- Physical infrastructure (buildings, workplaces, facilities, utilities)
|
||||
- Equipment (office equipment, manufacturing equipment, tools, spare parts)
|
||||
- ICT systems (applications, cloud services, remote access)
|
||||
- Transportation and logistics
|
||||
- Finance
|
||||
- Partners and suppliers
|
||||
- **Identifying and Documenting Dependencies**
|
||||
The BIA process should identify the dependencies between activities and resources. This involves documenting the quantity, time frame, characteristics, and dependencies of each resource required for an activity. For example, for IT resources, specific details like software versions, hardware specifications, and data backup regimes would be essential. Recognizing these dependencies helps in developing appropriate recovery strategies and solutions.
|
||||
- **Analyzing and Consolidating Dependencies**
|
||||
When analyzing and consolidating the BIA results, it's vital to recognize and address potential conflicts or inconsistencies arising from the interdependencies between activities and resources. For example, if the recovery objectives of one activity conflict with the resource availability for another, these issues need to be resolved.
|
||||
|
||||
The ISO 22317 emphasizes the need for a holistic approach when conducting a BIA. This involves understanding not just the direct impact of a disruption on individual processes or assets but also the ripple effect it can have due to the complex network of dependencies within and outside the organization. By mapping these dependencies and analyzing their potential impact, organizations can develop more robust business continuity plans and ensure a more resilient operation.
|
||||
17
Corpus/Standards/ISO27x/about/ISO 27000 MoC.md
Normal file
17
Corpus/Standards/ISO27x/about/ISO 27000 MoC.md
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
# About ISO 27000
|
||||
|
||||
## Chapter 3: Terms and Conditions
|
||||
|
||||
- 3.39 level of risk = magnitude of a risk expressed as the combination of consequences and their likelihood
|
||||
- 3.40 likelihood = chance of something happening
|
||||
- 3.57 residual risk = risk remaining after risk treatment
|
||||
- 3.61 risk = effect of uncertainty on objectives (positive or negative) – Note 5 to entry: In the context of information security management systems, information security risks can be expressed as effect of uncertainty on information security objectives"
|
||||
- 3.62 risk acceptance = informed decision to take a particular risk – (but still subject to monitoring and review as per note 2 to the entry)
|
||||
|
||||
## Chapter 4: ...
|
||||
### 4.2.4 Management
|
||||
"In terms of an ISMS, management involves the supervision and making of decisions necessary to achieve business objectives through the protection of the organization's information assets. Management of information security is expressed through the formulation and use of information security policies, procedures and guidelines, which are then applied throughout the organization by all individuals associated with the organization."
|
||||
|
||||
|
||||
[ISO 27000 PDF](ISO%2027000%20PDF.md)
|
||||
[ISO 27000 Overview and Vocabulary](ISO%2027000%20Overview%20and%20Vocabulary.md)
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
## ISO 27000 Version 2018-02
|
||||
|
||||
3.61
|
||||
**risk**
|
||||
effect of uncertainty on objectives (3.49)
|
||||
|
||||
Note 1 to entry: An effect is a deviation from the expected — positive or negative.
|
||||
|
||||
Note 2 to entry: Uncertainty is the state, even partial, of deficiency of information related to, understanding or knowledge of, an event, its consequence, or likelihood.
|
||||
|
||||
Note 3 to entry: Risk is often characterized by reference to potential “events” (as defined in ISO Guide 73:2009, 3.5.1.3) and “consequences” (as defined in ISO Guide 73:2009, 3.6.1.3), or a combination of these.
|
||||
|
||||
Note 4 to entry: Risk is often expressed in terms of a combination of the consequences of an event (including changes in circumstances) and the associated “likelihood” (as defined in ISO Guide 73:2009, 3.6.1.1) of occurrence.
|
||||
|
||||
Note 5 to entry: In the context of information security management systems, information security risks can be expressed as effect of uncertainty on information security objectives.
|
||||
|
||||
Note 6 to entry: Information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization.
|
||||
|
||||
## NEN 7510-1 2024
|
||||
3.1.70 **risico**
|
||||
effect van onzekerheid op het behalen van doelstellingen
|
||||
|
||||
Opmerking 1 bij de term:
|
||||
|
||||
Een effect is een afwijking ten opzichte van de verwachting – positief of negatief.
|
||||
|
||||
Opmerking 2 bij de term: Onzekerheid is het geheel of gedeeltelijk ontbreken van informatie over, inzicht in of kennis van een gebeurtenis, de gevolgen daarvan of de waarschijnlijkheid dat deze zich voordoet.
|
||||
|
||||
Opmerking 3 bij de term: Een risico wordt vaak gekarakteriseerd door verwijzingen naar potentiële gebeurtenissen (zoals gedefinieerd in NPR-ISO Guide 73:2009, 3.5.1.3) en gevolgen (zoals gedefinieerd in NPR-ISO Guide 73:2009, 3.6.1.3), of een combinatie daarvan.
|
||||
|
||||
Opmerking 4 bij de term: Een risico wordt vaak uitgedrukt als een combinatie van de gevolgen van een gebeurtenis (met inbegrip van wijzigingen in omstandigheden) en de bijbehorende waarschijnlijkheid dat de gebeurtenis zich voordoet.
|
||||
|
||||
Opmerking 5 bij de term: In de context van managementsystemen voor informatiebeveiliging kunnen informatiebeveiligingsrisico’s worden uitgedrukt als een effect van onzekerheid over de informatiebeveiligingsdoelstellingen.
|
||||
|
||||
Opmerking 6 bij de term: Informatiebeveiligingsrisico wordt geassocieerd met de mogelijkheid dat bedreigingen gebruik zullen maken van zwakke punten van een informatiebedrijfsmiddel of een groep informatiebedrijfsmiddelen, en de organisatie daarbij schade toebrengen.
|
||||
|
||||
[BRON: NPR-ISO Guide 73:2009, 1.1, gewijzigd – Opmerkingen 1 en
|
||||
3
Corpus/Standards/ISO27x/about/ISO 27000 PDF.md
Normal file
3
Corpus/Standards/ISO27x/about/ISO 27000 PDF.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
# ISO 27000 Fundamentals of information security management systems (ISMS)
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
When you start with ISO 27001, the key to looking at this bewildering list of controls is not to see this as a todo list or an implementation plan, but as a checklist, asking yourself for each control: how are we doing this at the moment?
|
||||
|
||||
Because if you have a sensible approach to your information, your devices and the services you use, chances are you have actually implemented most of them, at least partially. Let's start with some low-hanging fruit:
|
||||
|
||||
- [ ] Examples of 'common' controls.
|
||||
- [ ] backups
|
||||
- [ ] cryptography
|
||||
- [ ] physical security
|
||||
- [ ] password protection
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
# ISO 27001 Certification audit
|
||||
- [ ] compare requirements below, with KIWA document
|
||||
|
||||
|
||||
The certification audit must be performed by a certified auditor, and only a recognized Certification Body can issue a ISO 27001 certificate.
|
||||
|
||||
See also this [FAQ on ISMS audits and certification](https://www.iso27001security.com/html/audit_-_certification.html).
|
||||
|
||||
|
||||
## Stage 1 audit: Document review
|
||||
The auditor looks for:
|
||||
- the documented scope,
|
||||
- ISMS policy and objectives,
|
||||
- description of the risk assessment methodology,
|
||||
- Risk Assessment Report,
|
||||
- Risk Treatment Plan
|
||||
- procedures for document control
|
||||
- procedures for corrective and preventive actions
|
||||
- procedures for internal audit.
|
||||
- Statement of Applicability,
|
||||
- Documentation of applicable Annex A controls
|
||||
- inventory of assets (A.7.1.1),
|
||||
- acceptable use of assets (A.7.1.3),
|
||||
- roles and responsibilities of employees, contractors and third party users (A.8.1.1),
|
||||
- terms and conditions of employment (A.8.1.3),
|
||||
- procedures for the operation of information processing facilities (A.10.1.1),
|
||||
- access control policy (A.11.1.1),
|
||||
- identification of applicable legislation (A.15.1.1).
|
||||
- records of at least one internal audit and management review.
|
||||
|
||||
Only if all these requirements are met, you pass on to Stage 2.
|
||||
|
||||
## Stage 2 audit: Main audit
|
||||
Usually follows a few weeks after Stage 1 audit.
|
||||
|
||||
The focus is on proof of actual implementation of your ISMS processes and controls.
|
||||
|
||||
This is checked mainly by asking for records of activities, but also through observation and employee interviews.
|
||||
|
||||
Mandatory records include education, training, skills, experience and qualifications (5.2.2), internal audit (6), management review (7.1), corrective (8.2) and preventive (8.3) actions; however, the auditor will be expecting to see many more records as a result of carrying out your procedures.
|
||||
|
||||
## Report
|
||||
The auditor will report the findings using 3 categories:
|
||||
|
||||
- Observations, which may be handled by the organization as it sees fit
|
||||
- Minor non-conformities: which are deviations from the standard that do not affect the ability to achieve the ISMS's goals. They require drafting a Corrective Action Plan to resolve the issue
|
||||
- Major non-conformities, which do affect the ISMS's ability to achieve the intended results. These prevent the certificate from being issued.
|
||||
|
||||
The auditor will report the findings, with a deadline for resolving the non-conformities, usually 90 days. After resolving the issue, you notify the auditor and supply evidence. If you've done this well, the auditor will accept your corrective action issue the certificate.
|
||||
|
||||
Source: [Advisera](https://advisera.com/27001academy/blog/2010/02/15/how-to-get-certified-against-iso-27001/), retrieved December 13, 2021
|
||||
|
||||
### Reasons for major non-conformities
|
||||
|
||||
- If a company completely failed to fulfill a certain requirement – e.g., it didn’t perform management review at all, although this was required by the standard.
|
||||
- If your process has completely fallen apart – e.g., your procedure required you to perform backup once a day, whereas the backup was performed only a couple of times per month, randomly.
|
||||
- If you have several minor nonconformities that are related to the same process or to the same element of your management system – e.g., you have several minor nonconformities related to your Human resources department: some of the training records are missing, not all employees are trained as they should be, some of the employment records are missing, etc. – this becomes a major nonconformity because there is obviously something very wrong with this department.
|
||||
- If a certification mark is misused – e.g., you claim to your customers that your product is ISO certified (certification of ISO management standards covers only the processes and management systems, not the products themselves).
|
||||
- If a minor nonconformity, raised during the previous audit, has not been resolved within the deadline – such a small nonconformity automatically becomes a major one.
|
||||
|
||||
Source: [Advisera](https://advisera.com/27001academy/blog/2014/06/02/major-vs-minor-nonconformities-in-the-certification-audit/), retrieved December 13, 2021
|
||||
|
||||
See also: [Dealing with non-conformities](https://info-savvy.com/iso-27001-clause-10-1-non-conformity-and-corrective-action/)
|
||||
|
||||
## Nico Nijenhuis, TüV, 10 juni 2020
|
||||
- Wordt bij TüV 3 maanden vooruit gepland
|
||||
- Er staat een vast aantal dagen voor, dat is in de norm bepaald
|
||||
* Je kunt vooraf evt een proefaudit laten doen
|
||||
* Certificering bestaat uit 2 fasen:
|
||||
* Fase 1 - documentatie onderzoek - is de verplichte documentatie aanwezig (of is aantoonbaar vastgesteld dat bepaalde zaken geregeld zijn.) – de norm noemt op verschillende punten “gedocumenteerde informatie”
|
||||
* Na enkele weken volgt Fase 2: interviews en audits per onderwerp/afdeling
|
||||
* Daarna wordt de rapportage opgemaakt
|
||||
* Waar er sprake is van non-conformity krijg je 12 weken de tijd om het op te lossen
|
||||
* Indien opgelost volgt er een certificaat
|
||||
* Als er een groter probleem is, is er langere tijd en een tweede certificeringsronde nodig.
|
||||
|
||||
1. Observatie: mag je zelf actiepunten voor definiëren, doe je er niets mee, dan escaleert het naar …
|
||||
2. Niet-kritieke afwijking —> Corrective Action Plan; indien niet opgelost, escalatie naar …
|
||||
3. Kritieke afwijking —> je krijgt uitstel om het op te lossen, is show stopper voor certificaat.
|
||||
|
||||
CAP: Corrective Action Plan
|
||||
|
||||
|
||||
Related: [ISO 17021 Conformity assessment](ISO%2017021%20Conformity%20assessment.md)
|
||||
|
||||
### Audit cyclus
|
||||
* Het certificaat is 3 jr geldig
|
||||
* Binnen die 3 jaar zijn er 2 controle audits
|
||||
* Na 3 jaar moet je op voor hercertificering
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
De ISO 27001 en 27002 normen beschouwen documentatie, beleidsstukken, procedures en registraties als "gedocumenteerde informatie" en vallen onder de bredere definitie van **bedrijfsmiddelen (assets)**. [^1][^2]De norm eist geen centrale "documentatie-eigenaar" voor de hele organisatie, maar hanteert een gedecentraliseerde aanpak waarbij het eigenaarschap afhankelijk is van het soort document.
|
||||
|
||||
Volgens beheersmaatregel [A.5.9](../../MoCs/ISO_27002_2022_5.9_MoC%20Inventory%20of%20information%20and%20other%20associated%20assets.md) (Inventarisatie van bedrijfsmiddelen) moet álle informatie en gerelateerde bedrijfsmiddelen een specifieke **eigenaar** toegewezen krijgen. Deze eigenaar is verantwoordelijk voor het juiste beheer van de documentatie gedurende de hele levenscyclus, waaronder de classificatie, toegangsbeperkingen en de periodieke beoordeling ervan.
|
||||
|
||||
De norm geeft specifieke richtlijnen over waar de verantwoordelijkheid voor de verschillende soorten documentatie zou moeten liggen:
|
||||
|
||||
**1. Het overkoepelende Informatiebeveiligingsbeleid** Dit is het document op het hoogste niveau. De norm eist expliciet dat de verantwoordelijkheid voor het vaststellen en goedkeuren van dit beleid uitsluitend bij het **topmanagement (de directie)** ligt.
|
||||
|
||||
**2. Onderwerpspecifieke beleidsregels** Voor meer gedetailleerde of specifieke beleidsregels (zoals beleid voor toegangsbeveiliging, cryptografie of werken op afstand) ligt de verantwoordelijkheid voor het ontwikkelen, beoordelen en goedkeuren bij **relevant personeel op basis van een passend bevoegdheidsniveau en technische bekwaamheid**. Dit betekent dat het eigenaarschap hier doorgaans bij de systeemeigenaren, security officers of afdelingsmanagers ligt (het "passende managementniveau", zie [A.5.1](../legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md)).
|
||||
|
||||
**3. Gedocumenteerde bedieningsprocedures** Voor werkinstructies en bedieningsprocedures (zoals omschreven in [A.5.37](../../MoCs/ISO_27002_2022_5.37_MoC%20Documented%20operating%20procedures.md)) eist de norm dat in de documentatie zélf expliciet wordt gespecificeerd **welke personen verantwoordelijk zijn** voor de in de procedure beschreven activiteiten.
|
||||
|
||||
**4. Registraties en bewijsmateriaal (Artifacts)** Registraties zijn informatie (zoals logbestanden, auditrapporten, of goedkeuringsformulieren) die als bewijs worden bewaard om aan te tonen dat processen volgens planning zijn uitgevoerd[^3] (zie [C.8.1](../../MoCs/ISO_27001_2022_8.1_MoC%20Operational%20planning%20and%20control.md)). Zoals het TypeDB-dataschema uit de bronnen illustreert, kunnen deze documenten als _artifacts_ worden gezien, waaraan specifieke actoren (zoals een persoon of organisatie) gekoppeld moeten zijn via een verantwoordelijkheidsrelatie (bijv. in de rol van eigenaar of beheerder).
|
||||
|
||||
**Algemene eisen aan documentatie-eigenaarschap (ISO 27001, Hoofdstuk 7.5)** Bij het creëren en actualiseren van élk stuk gedocumenteerde informatie eist de norm dat de organisatie zorgt voor:
|
||||
|
||||
- Passende identificatie en beschrijving, waarbij de norm expliciet de **auteur** als voorbeeld van een vereist kenmerk noemt.
|
||||
- Een proces voor formele **beoordeling en goedkeuring** van de geschiktheid en toereikendheid van het document. Dit impliceert dat er altijd iemand met de juiste autoriteit is aangewezen om de inhoud te valideren.
|
||||
|
||||
Zie [C.7.5.2](../../MoCs/ISO_27001_2022_7.5.2_MoC%20Creating%20and%20updating.md).
|
||||
|
||||
---
|
||||
|
||||
|
||||
[^1]: 3.1 Termen en definities > Bedrijfsmiddel
|
||||
|
||||
[^2]: 7.5 Gedocumenteerde informatie > 7.5.1 Algemeen
|
||||
|
||||
[^3]: 3.1 Termen en definities > Term 3.1.28 registratie
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
# ISO 27001 Leadership Responsibilities
|
||||
|
||||
*Note that I asked a follow-up to list the responsibilities exclusive to "Top Management vs. other unspecified management layers" – the response can be found [here](ISO%2027001%20Top%20Management%20responsibilities.md).*
|
||||
|
||||
ISO 27001 and ISO 27002 place the ultimate responsibility and accountability for the Information Security Management System (ISMS) on **Top Management**. This is codified primarily in **Clause 5** of ISO 27001 and supported by **Control 5.4** in ISO 27002.
|
||||
|
||||
The standards outline the responsibilities of leadership as follows:
|
||||
### 1. Leadership and Commitment (ISO 27001)
|
||||
|
||||
Top management must demonstrate leadership and commitment to the ISMS. They are explicitly accountable for the effectiveness of the system. Their specific responsibilities include:
|
||||
|
||||
- **Strategic Alignment:** Ensuring the information security policy and objectives are established and compatible with the strategic direction of the organization.
|
||||
- **Integration:** Ensuring that ISMS requirements are integrated into the organization’s processes.
|
||||
- **Resourcing:** Ensuring that the resources needed for the ISMS are available.
|
||||
- **Communication:** Communicating the importance of effective information security management and conforming to ISMS requirements.
|
||||
- **Outcomes:** Ensuring the ISMS achieves its intended outcomes.
|
||||
- **Support:** Directing and supporting persons to contribute to the effectiveness of the ISMS and supporting other relevant management roles to demonstrate leadership in their specific areas.
|
||||
- **Improvement:** Promoting continual improvement.
|
||||
|
||||
This is all described in [Clause 5.1](../../MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md).
|
||||
### 2. Policy Establishment (ISO 27001 & ISO 27002)
|
||||
|
||||
Top management is responsible for establishing an information security policy that is appropriate to the purpose of the organization.
|
||||
|
||||
- **Approval:** The policy must be formally approved by top management.
|
||||
- **Changes:** Any changes to the policy must be approved by top management.
|
||||
|
||||
This is described in [Clause 5.2](../../MoCs/ISO_27001_2022_5.2_MoC%20Policy.md) and [Control 5.1](../legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md).
|
||||
### 3. Organizational Roles and Authorities (ISO 27001)
|
||||
|
||||
Top management must ensure that responsibilities and authorities for roles relevant to information security are assigned and communicated within the organization. specifically, they must assign the responsibility and authority for:
|
||||
|
||||
- Ensuring the ISMS conforms to the requirements of the standard.
|
||||
- Reporting on the performance of the ISMS to top management.
|
||||
|
||||
This is described in Clauses [5.2](../../MoCs/ISO_27001_2022_5.2_MoC%20Policy.md) and [5.3](../../MoCs/ISO_27001_2022_5.3_MoC%20Organizational%20roles,%20responsibilities%20and%20authorities.md).
|
||||
### 4. Management Responsibilities regarding Personnel (ISO 27002)
|
||||
|
||||
**[Control 5.4](../../MoCs/ISO_27002_2022_5.4_MoC%20Management%20responsibilities.md) (Management responsibilities)** specifies that management should require all personnel to apply information security in accordance with the established policies and procedures.
|
||||
|
||||
To fulfill this, management should ensure that personnel:
|
||||
|
||||
- Are properly briefed on their roles and responsibilities before being granted access to information.
|
||||
- Are provided with guidelines stating information security expectations.
|
||||
- Are mandated to fulfill the information security policy.
|
||||
- Achieve a level of awareness relevant to their roles.
|
||||
- Are provided with a confidential channel for reporting violations ("whistleblowing") where practicable.
|
||||
- Are provided with adequate resources and project planning time for implementing security processes.
|
||||
|
||||
### 5. Oversight and Review
|
||||
|
||||
- **Management Review:** Top management is required to review the organization's ISMS at planned intervals to ensure its continuing suitability, adequacy, and effectiveness. This review includes making decisions related to continual improvement and resource needs.
|
||||
- **Independent Review:** The results of independent reviews of the ISMS should be reported to the management who initiated the review and, if appropriate, to top management. If the review identifies that the approach to managing information security is inadequate, management must initiate corrective actions.
|
||||
|
||||
Described in [Clause 9.3](../../MoCs/ISO_27001_2022_9.3_MoC%20Management%20review.md) and [Control 5.35](../../MoCs/ISO_27002_2022_5.35_MoC%20Independent%20review%20of%20information%20security.md).
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
|
||||
> The Statement of Applicability (SoA) forms a fundamental part of your information security management system (ISMS). The SoA is one of the most important documents you’ll need to develop for ISO 27001:2013 certification.
|
||||
> Put simply, in its quest to protect valuable information assets and manage the information processing facilities, the SoA states what ISO 27001 controls and policies are being applied by the organisation. It benchmarks against the Annex A control set in the ISO 27001 standard
|
||||
> The statement of applicability is found in 6.1.3 of the main requirements for ISO 27001, which is part of the broader 6.1, focused on actions to address risks and opportunities. The SoA is therefore an integral part of the mandatory ISO 27001 documentation that needs to be presented to an external auditor when the ISMS is undergoing an independent audit e.g. by a UKAS audit certification body.
|
||||
|
||||
Source: [ISMS.online](https://www.isms.online/iso-27001/iso27001-statement-applicability-simplified/), retrieved December 2, 2021
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# ISO 27001 Top Management responsibilities
|
||||
|
||||
Based on the provided sources, particularly **ISO/IEC 27001 Clause 5** and **Clause 9.3**, specific responsibilities are assigned explicitly to **"Top Management"**. These are distinct from general "management" responsibilities (such as those in ISO 27002 Control 5.4), which apply to all levels of supervision (line managers, project managers, etc.).
|
||||
|
||||
The responsibilities **exclusive to Top Management** focus on strategic alignment, resource provision, and ultimate accountability for the ISMS. They include:
|
||||
### 1. Strategic Alignment and Policy Establishment
|
||||
|
||||
Only Top Management is explicitly required to:
|
||||
|
||||
- **Establish the Policy:** They must establish the information security policy.
|
||||
- **Ensure Strategic Compatibility:** They must ensure that the information security policy and objectives are compatible with the **strategic direction** of the organization.
|
||||
- **Ensure Process Integration:** They must ensure that ISMS requirements are integrated into the organization’s broader business processes.
|
||||
|
||||
### 2. Resource Provision
|
||||
|
||||
While other managers utilize resources, Top Management is exclusively responsible for **ensuring the resources needed** for the ISMS are available. This implies budgetary and organizational authority that lower management layers typically do not possess independently.
|
||||
|
||||
### 3. Assignment of Roles and Authority
|
||||
|
||||
Top Management has the exclusive duty to assign and communicate responsibilities and authorities within the organization. Specifically, they must assign the responsibility for:
|
||||
|
||||
- Ensuring the ISMS conforms to the standard.
|
||||
- **Reporting performance** of the ISMS back _to_ Top Management.
|
||||
|
||||
### 4. Management Review
|
||||
|
||||
Top Management is explicitly required to conduct the **Management Review** (Clause 9.3) at planned intervals. This is a formal evaluation of the ISMS's continuing suitability, adequacy, and effectiveness, which includes making decisions on:
|
||||
|
||||
- Changes to the ISMS.
|
||||
- Opportunities for continual improvement.
|
||||
|
||||
### 5. Ultimate Accountability
|
||||
|
||||
Clause 5.1 states that Top Management shall demonstrate leadership by "ensuring that the information security management system achieves its intended outcome(s)". While operational managers work towards this, the standard places the ultimate requirement of _ensuring_ success on Top Management.
|
||||
|
||||
### Comparison: What is _Not_ Exclusive to Top Management?
|
||||
|
||||
In contrast, **ISO 27002 Control 5.4** refers simply to "**Management** responsibilities" rather than "Top Management." The following tasks are responsibilities of _all_ management layers (line managers, supervisors), not exclusively Top Management:
|
||||
|
||||
- Briefing personnel on roles and responsibilities before granting access.
|
||||
- Ensuring personnel are provided with guidelines and achieve necessary awareness.
|
||||
- Ensuring personnel comply with terms and conditions of employment.
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
tags:
|
||||
- iso27001
|
||||
- audit
|
||||
---
|
||||
|
||||
2
Corpus/Standards/ISO27x/about/ISO 27001 audit process.md
Normal file
2
Corpus/Standards/ISO27x/about/ISO 27001 audit process.md
Normal file
|
|
@ -0,0 +1,2 @@
|
|||
https://www.isms.online/iso-27001/what-is-the-iso-27001-audit-process/
|
||||
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
# ISO 27001 enumerated list of controls
|
||||
|
||||
5.1 Policies for information security
|
||||
5.2 Information security roles and responsibilities
|
||||
5.3 Segregation of duties
|
||||
5.4 Management responsibilities
|
||||
5.5 Contact with authorities
|
||||
5.6 Contact with special interest groups
|
||||
5.7 Threat intelligence
|
||||
5.8 Information security in project management
|
||||
5.9 Inventory of information and other associated assets
|
||||
5.10 Acceptable use of information and other associated assets
|
||||
5.11 Return of assets
|
||||
5.12 Classification of information
|
||||
5.13 Labelling of information
|
||||
5.14 Information transfer
|
||||
5.15 Access control
|
||||
5.16 Identity management
|
||||
5.17 Authentication information
|
||||
5.18 Access rights
|
||||
5.19 Information security in supplier relationships
|
||||
5.20 Addressing information security within supplier agreements
|
||||
5.21 Managing information security in the ICT supply chain
|
||||
5.22 Monitoring, review and change management of supplier services
|
||||
5.23 Information security for use of cloud services
|
||||
5.24 Information security incident management planning and preparation
|
||||
5.25 Assessment and decision on information security events
|
||||
5.26 Response to information security incidents
|
||||
5.27 Learning from information security incidents
|
||||
5.28 Collection of evidence
|
||||
5.29 Information security during disruption
|
||||
5.30 ICT readiness for business continuity
|
||||
5.31 Legal, statutory, regulatory and contractual requirements
|
||||
5.32 Intellectual property rights
|
||||
5.33 Protection of records
|
||||
5.34 Privacy and protection of PII
|
||||
5.35 Independent review of information security
|
||||
5.36 Compliance with policies, rules and standards for information security
|
||||
5.37 Documented operating procedures
|
||||
6.1 Screening
|
||||
6.2 Terms and conditions of employment
|
||||
6.3 Information security awareness, education and training
|
||||
6.4 Disciplinary process
|
||||
6.5 Responsibilities after termination or change of employment
|
||||
6.6 Confidentiality or non-disclosure agreements
|
||||
6.7 Remote working
|
||||
6.8 Information security event reporting
|
||||
7.1 Physical security perimeters
|
||||
7.2 Physical entry
|
||||
7.3 Securing offices, rooms and facilities
|
||||
7.4 Physical security monitoring
|
||||
7.5 Protecting against physical and environmental threats
|
||||
7.6 Working in secure areas
|
||||
7.7 Clear desk and clear screen
|
||||
7.8 Equipment siting and protection
|
||||
7.9 Security of assets off-premises
|
||||
7.10 Storage media
|
||||
7.11 Supporting utilities
|
||||
7.12 Cabling security
|
||||
7.13 Equipment maintenance
|
||||
7.14 Secure disposal or re-use of equipment
|
||||
8.1 User endpoint devices
|
||||
8.2 Privileged access rights
|
||||
8.3 Information access restriction
|
||||
8.4 Access to source code
|
||||
8.5 Secure authentication
|
||||
8.6 Capacity management
|
||||
8.7 Protection against malware
|
||||
8.8 Management of technical vulnerabilities
|
||||
8.9 Configuration management
|
||||
8.10 Information deletion
|
||||
8.11 Data masking
|
||||
8.12 Data leakage prevention
|
||||
8.13 Information backup
|
||||
8.14 Redundancy of information processing facilities
|
||||
8.15 Logging
|
||||
8.16 Monitoring activities
|
||||
8.17 Clock synchronization
|
||||
8.18 Use of privileged utility programs
|
||||
8.19 Installation of software on operational systems
|
||||
8.20 Networks security
|
||||
8.21 Security of network services
|
||||
8.22 Segregation of networks
|
||||
8.23 Web filtering
|
||||
8.24 Use of cryptography
|
||||
8.25 Secure development life cycle
|
||||
8.26 Application security requirements
|
||||
8.27 Secure system architecture and engineering principles
|
||||
8.28 Secure coding
|
||||
8.29 Security testing in development and acceptance
|
||||
8.30 Outsourced development
|
||||
8.31 Separation of development, test and production environments
|
||||
8.32 Change management
|
||||
8.33 Test information
|
||||
8.34 Protection of information systems during audit testing
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
# Examples of ISO 27001 Scope Statements
|
||||
|
||||
## 2ICT
|
||||
> Informatiebeveiliging gerelateerd aan het leveren van online werkplekken en aanvullende clouddiensten, in overeenstemming met de Verklaring van Toepasselijkheid Versie 1.5 - 18-02-2021.
|
||||
|
||||
## Intermail
|
||||
> Advise, implement, enhance, support and perform data services, hardware and data connections for the DM activities, as claimed in the Statement of Applicability, version 7, 22 March 2019. (Intermail)
|
||||
|
||||
## IC Solutions
|
||||
> De scope van informatiebeveiligingsmanagementsysteem omvat alle processen van IC Solutions, de onderliggende informatiesystemen, informatie en gegevens, diensten van externe partijen en het gebruik daarvan door medewerkers en (keten)partners, ongeacht locatie, tijdstip en gebruikte apparatuur.
|
||||
> Het leveren en beheren van hosted werkplekken en e-mail en gerelateerde hosting diensten, zoals vastgesteld door het management en in overeenstemming met de Verklaring van Toepasselijkheid, versie 1.4 d.d. 07-03-2019.
|
||||
|
||||
## Pixelpool
|
||||
> Develop, maintain and manage a specialized software solution for the fashion industry, called Dtail. As well as producing and visualizing 3D content for the fashion industry.
|
||||
|
||||
>As part of its services, PixelPool securely handles and manages confidential business data of its clients.
|
||||
The confidential data is stored and handled in 4 systems:
|
||||
· On-premises servers, partially managed by an IT partner
|
||||
· Data center backup server, managed by an IT partner
|
||||
· Microsoft 365 and SharePoint, partially managed by an IT partner
|
||||
· Cloud computing and cloud storage, managed by AWS (Amazon Web Service)
|
||||
30
Corpus/Standards/ISO27x/about/ISO 27001 stage 1 audit.md
Normal file
30
Corpus/Standards/ISO27x/about/ISO 27001 stage 1 audit.md
Normal file
|
|
@ -0,0 +1,30 @@
|
|||
---
|
||||
tags:
|
||||
- iso27001
|
||||
- audit
|
||||
---
|
||||
|
||||
Our Stage 1 audit is coming up soon. If you’ve done this before as a startup, what did your auditor focus on during Stage 1?
|
||||
|
||||
> Buy the standards:
|
||||
> - ISO27001 - it describes the "what"
|
||||
> - ISO27002 - it describes the "how" in relation to the controls
|
||||
> - ISO27003 - it describes the "how" in relation to the harmonised structure.
|
||||
|
||||
>All depends on your auditor, but in general they look if you are ready for the audit. You should have had an internal audit, that should give you a lot of information on what you are missing. In my experience they focus on the management system, so not so much the annex. Just read this part of the standard and make sure you comply with all that is requested there.
|
||||
>Focus on risk analysis, stakeholders, incident response, policies, internal audit, improvement register.
|
||||
|
||||
> You need to first perform a gap assessment. Document each requirement in the standard, including those defined in the Management Clauses, and simply measure yourself against how you meet each control.
|
||||
>
|
||||
> 1: Not Ready 2: We’re there 3: We’re there and have evidence.
|
||||
>
|
||||
> Additionally, you’ll need to have an Internal Audit performed by a competent 27001 auditor before you can get certified, it’s a requirement of the management clauses. This Internal Audit can prepare you for what you may be missing before the certification body auditors find issues.
|
||||
|
||||
> Stage 1 is a "readiness assessment" and document audit.
|
||||
> There are very few documents that ISO 27001 actually mandates - like, about 12. The auditor will be checking that you have those required docs, and that you have any docs that you have said you need.
|
||||
> Search the Standard for: "shall be documented" and "documentation shall be maintained", you'll find most of the stuff you MUST have.
|
||||
>
|
||||
> You also MUST do a whole system internal audit BEFORE you reach Stage 2 (or MajorNC), and it's a really good idea to do it, or most of it, before Stage 1. A decent internal audit will help you find anything that's missing.
|
||||
|
||||
> As others said, first stage is primarily ISMS strategy and having documentation/processes in order.
|
||||
|
||||
3
Corpus/Standards/ISO27x/about/ISO 27003.md
Normal file
3
Corpus/Standards/ISO27x/about/ISO 27003.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
# ISO 27003 Process-oriented approach to the successful implementation of the ISMS in accordance with 27001
|
||||
|
||||
|
||||
5
Corpus/Standards/ISO27x/about/ISO 27004.md
Normal file
5
Corpus/Standards/ISO27x/about/ISO 27004.md
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
# ISO 27004 Monitoring, measurement, analysis and evaluation
|
||||
|
||||
Measurement framework allowing an assessment of ISMS effectiveness
|
||||
|
||||
|
||||
4
Corpus/Standards/ISO27x/about/ISO 27005.md
Normal file
4
Corpus/Standards/ISO27x/about/ISO 27005.md
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
# ISO 27005
|
||||
Guidance on implementing a process-oriented risk management approach
|
||||
|
||||
|
||||
3
Corpus/Standards/ISO27x/about/ISO 27017.md
Normal file
3
Corpus/Standards/ISO27x/about/ISO 27017.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
# ISO 27017 Code of practice for information security controls for cloud services
|
||||
|
||||
|
||||
4
Corpus/Standards/ISO27x/about/ISO 27018.md
Normal file
4
Corpus/Standards/ISO27x/about/ISO 27018.md
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
# ISO 27018 Code of practice for protection of personally identifiable information in public clouds
|
||||
|
||||
|
||||
|
||||
327
Corpus/Standards/ISO27x/about/ISO 27028.md
Normal file
327
Corpus/Standards/ISO27x/about/ISO 27028.md
Normal file
|
|
@ -0,0 +1,327 @@
|
|||
---
|
||||
tags:
|
||||
- iso27028
|
||||
- LLMgenerated
|
||||
---
|
||||
# ISO 27028 Guidance on ISO/IEC 27002 attributes
|
||||
Still in development as per 3 juli 2025
|
||||
|
||||
ISO/IEC TS 27028, "Information security, cybersecurity and privacy protection — Guidance on ISO/IEC 27002 attributes," is a technical specification that aims to provide guidance on the use and development of attributes aligned with ISO/IEC 27002:2022.1 Essentially, it helps organizations better classify, select, and design information security controls for various purposes.
|
||||
|
||||
While ISO 27002 provides a catalog of information security controls, ISO 27028 delves deeper into how to categorize and use these controls effectively through the concept of "attributes." These attributes can help an organization understand the characteristics of a control (e.g., preventive, detective, corrective) and how it contributes to their overall information security posture.
|
||||
|
||||
# Practical applications of ISO 27028
|
||||
|
||||
Here are some practical applications of ISO 27028:
|
||||
|
||||
- **Tailoring Information Security Management Systems (ISMS):**
|
||||
|
||||
- **Risk-based control selection:** Organizations can use the attributes to select controls that are most relevant to their specific risks and business needs. For example, if a high risk is identified for data confidentiality, the attributes can help identify preventive controls that directly address this.
|
||||
|
||||
- **Customizing control sets:** While ISO 27002 offers a comprehensive list, not every control is applicable to every organization.5 ISO 27028 can help in developing customized sets of controls based on attribute values, ensuring that only necessary and effective controls are implemented.
|
||||
|
||||
- **Optimizing resource allocation:** By understanding the attributes of controls, organizations can prioritize investments in security measures that provide the greatest impact on mitigating identified risks, optimizing their security budget.
|
||||
|
||||
- **Improving Control Effectiveness and Assurance:**
|
||||
|
||||
- **Enhanced control design:** The guidance in ISO 27028 can help organizations design more robust controls by considering various attributes during the implementation phase.
|
||||
|
||||
- **Better monitoring and reporting:** Attributes can be used to categorize and track the performance of controls. This allows for more meaningful monitoring, measurement, and reporting of security posture to management and stakeholders.
|
||||
|
||||
- **Auditing and compliance:** Auditors can use the attribute-based approach to assess the completeness and effectiveness of an organization's controls against specific requirements, whether internal policies or external regulations.
|
||||
|
||||
- **Facilitating Communication and Understanding:**
|
||||
|
||||
- **Clearer security objectives:** By using attributes, security professionals can articulate the purpose and function of controls more clearly to non-technical stakeholders, fostering a better understanding of information security throughout the organization.
|
||||
|
||||
- **Standardized terminology:** The standard promotes a consistent way of describing and categorizing controls, which can improve communication and collaboration within an organization and with external partners.6
|
||||
|
||||
- **Responding to Evolving Threats:**
|
||||
|
||||
- **Adaptability:** The attribute-based approach allows organizations to be more agile in adapting their security controls as new threats and vulnerabilities emerge. They can quickly identify which types of controls are needed to address new risks.
|
||||
|
||||
- **Proactive security:** By considering attributes like "preventive" or "detective," organizations can build a more balanced and proactive security architecture rather than solely reacting to incidents.7
|
||||
|
||||
|
||||
In essence, ISO 27028 acts as a valuable tool for organizations that are serious about implementing and optimizing their information security management systems, moving beyond a simple checklist approach to a more intelligent and tailored application of security controls.
|
||||
|
||||
# Developing your own attributes
|
||||
|
||||
Here's how ISO 27028 supports the development of custom attributes:
|
||||
|
||||
- **Tailored Views:** Organizations can create attributes that provide **more granular or relevant perspectives** on their controls. For instance, a highly regulated industry might introduce attributes specific to their compliance obligations (e.g., "GDPR relevance" or "HIPAA applicability").
|
||||
|
||||
- **Enhanced Risk Treatment:** Custom attributes can help in **better linking controls to specific risks** identified in an organization's risk assessment. If a risk treatment plan requires controls with a very specific characteristic not covered by standard attributes, custom ones can fill that gap.
|
||||
|
||||
- **Improved Reporting:** Custom attributes allow organizations to **generate reports and metrics** that are more meaningful to their internal stakeholders and management. For example, an attribute for "responsible department" could enable clear reporting on ownership of controls.
|
||||
|
||||
- **Integration with Existing Frameworks:** If an organization uses other security frameworks (like NIST CSF or CIS Controls) alongside ISO 27001/27002, they can develop custom attributes that **map to the terminology and concepts of those frameworks**, facilitating integration and consistency.
|
||||
|
||||
- **Optimized Control Selection and Design:** By developing attributes that directly reflect their unique operational environment and security objectives, organizations can **make more informed decisions** about which controls to implement and how to design them effectively.
|
||||
|
||||
|
||||
Developing a system of specific attributes for information security controls, as guided by ISO/IEC TS 27028, is crucial for tailoring an organization's security posture. Here's what's important:
|
||||
|
||||
---
|
||||
|
||||
### Alignment with Organizational Context 🎯
|
||||
|
||||
The most critical aspect is ensuring the attributes **directly support your organization's unique needs, objectives, and risk profile**. This means:
|
||||
|
||||
- **Business Objectives:** Attributes should help in achieving specific business goals, such as maintaining service availability, protecting customer data, or ensuring regulatory compliance.
|
||||
|
||||
- **Risk Landscape:** They must be designed to classify controls in a way that directly assists in mitigating the organization's specific threats and vulnerabilities.
|
||||
|
||||
- **Regulatory & Compliance Requirements:** For organizations in regulated industries, attributes should facilitate demonstrating adherence to laws, standards, and industry-specific mandates (e.g., GDPR, HIPAA, PCI DSS).
|
||||
|
||||
- **Strategic Security Goals:** The attributes should reflect and reinforce the overarching security strategy of the organization.
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Clarity and Unambiguity 🧐
|
||||
|
||||
Each attribute and its possible values should be **clearly defined and easily understood** by anyone who will use them.
|
||||
|
||||
- **Precise Definitions:** Avoid vague language. Define what each attribute means and what its specific values represent. For example, if you have an attribute "Control Function," its values like "Preventive," "Detective," and "Corrective" should have clear definitions.
|
||||
|
||||
- **Mutual Exclusivity:** Where appropriate, attribute values should be mutually exclusive, meaning a control can only have one value for a given attribute to avoid confusion.
|
||||
|
||||
- **Consistency:** The application of attributes must be consistent across all controls and by all personnel involved in the process. This might require training and clear documentation.
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Practicality and Usability 🛠️
|
||||
|
||||
The attribute system must be **easy to implement and maintain** within your existing security processes.
|
||||
|
||||
- **Simplicity:** Don't overcomplicate it. Too many attributes or overly complex definitions can make the system cumbersome and lead to low adoption.
|
||||
|
||||
- **Integration:** Consider how the attribute system will integrate with existing tools and processes, such as risk management platforms, control frameworks, and reporting mechanisms.
|
||||
|
||||
- **Maintainability:** The system should be manageable. As your organization evolves, the attributes may need to be reviewed and updated. Ensure there's a process for this.
|
||||
|
||||
- **Actionability:** Attributes should provide actionable insights. They should help you make decisions about control selection, implementation, monitoring, and reporting. If an attribute doesn't lead to better decision-making, it might not be necessary.
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Scalability and Adaptability ⚖️
|
||||
|
||||
The attribute system should be **flexible enough to evolve** with your organization and the changing threat landscape.
|
||||
|
||||
- **Future-Proofing:** While you can't predict everything, design the system with some flexibility to accommodate new technologies, business processes, or emerging threats without a complete overhaul.1
|
||||
|
||||
- **Granularity:** Choose an appropriate level of granularity. Too broad, and the attributes are unhelpful; too fine, and they become unmanageable.2 Find a balance that provides meaningful insights without excessive detail.
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Communication and Documentation ✍️
|
||||
|
||||
Effective communication and thorough documentation are essential for the **successful adoption and longevity** of the attribute system.
|
||||
|
||||
- **Comprehensive Documentation:** Create clear documentation explaining each attribute, its purpose, its possible values, and how to apply it. This serves as a critical reference for users.
|
||||
|
||||
- **Training and Awareness:** Provide training to relevant stakeholders on how to use and interpret the attribute system.
|
||||
|
||||
- **Stakeholder Buy-in:** Involve key stakeholders from different departments (e.g., IT, legal, business units) in the development process to ensure their needs are met and to foster ownership.
|
||||
|
||||
|
||||
By focusing on these key aspects, organizations can develop a system of specific attributes that significantly enhances their ability to manage information security controls effectively and strategically.
|
||||
|
||||
# Methodologies Suggested by ISO 27028 for Developing and Applying Attributes
|
||||
|
||||
ISO 27028 provides structured guidance for organizations to develop and apply attributes to information security controls, building on the concepts introduced in ISO/IEC 27002:2022. The methodologies recommended include:
|
||||
|
||||
1. Event-Consequence Scenario Method
|
||||
• Event-consequence scenarios are central to ISO 27028’s approach. Organizations are encouraged to analyze potential security events and their consequences to identify which attributes are most relevant for their controls.
|
||||
• This scenario-based method helps in customizing attributes and their values to reflect the organization’s unique operational context and risk profile.
|
||||
2. Customization and Extension of Attributes
|
||||
• Organizations may modify, extend, or disregard the default attributes provided in ISO/IEC 27002.
|
||||
• ISO 27028 suggests a methodology for developing customized attributes, such as:
|
||||
• Defining new attributes based on organizational needs (e.g., department, asset type, maturity level, priority, implementation status).
|
||||
• Assigning attribute values that are meaningful for the organization’s structure and risk management processes.
|
||||
3. Attribute-Based Control Selection and Gap Analysis
|
||||
• Attributes can be used to classify, select, or design information security controls for various management and business purposes.
|
||||
• The methodology includes:
|
||||
• Using attributes to filter and select controls that align with specific security objectives (e.g., confidentiality, integrity, availability).
|
||||
• Applying attributes to identify gaps in the risk treatment plan and assess resilience against control failures.
|
||||
4. Iterative Review and Improvement
|
||||
• The process of developing and applying attributes is iterative. Organizations are advised to periodically review and refine attributes and their values based on lessons learned from incidents and changes in the operational environment.
|
||||
In summary:
|
||||
ISO 27028 emphasizes a practical, scenario-driven approach (event-consequence analysis), supports the customization of attributes, and encourages using attributes for control selection and ongoing risk management. This methodology is designed to help organizations tailor their security framework to their specific needs and enhance resilience.
|
||||
|
||||
## Using an Event-Consequence Scenario Method
|
||||
|
||||
### Overview
|
||||
|
||||
The **Event-Consequence Scenario Method** is a structured approach recommended by ISO 27028 for developing and applying attributes to information security controls. It guides organizations to analyze potential security events and their consequences, then use this analysis to tailor attributes that best reflect their operational context and risk profile. This method is particularly relevant for implementing and customizing controls from ISO/IEC 27002:2022[1][2].
|
||||
|
||||
#### Key Steps in the Method
|
||||
|
||||
- **Identify plausible security events:** Consider a range of possible incidents, from common to rare, that could impact the organization.
|
||||
- **Analyze consequences:** Assess the potential impact of each event on information assets, operations, and compliance.
|
||||
- **Map controls to scenarios:** Link specific ISO 27002 controls to the identified scenarios, evaluating how attributes (such as control type, security property, or operational capability) align with the organization's needs.
|
||||
- **Customize attributes:** Adjust or create new attributes based on the findings to improve control selection, risk treatment, and resilience[1][2].
|
||||
|
||||
### Examples Relevant to ISO 27002
|
||||
|
||||
Below are practical examples illustrating how the Event-Consequence Scenario Method can be applied to ISO 27002 controls:
|
||||
|
||||
#### Example 1: Ransomware Attack Scenario
|
||||
|
||||
- **Event:** Employee opens a phishing email, triggering ransomware.
|
||||
- **Consequence:** Critical business files are encrypted, leading to downtime, data loss, and possible ransom demands.
|
||||
- **Relevant ISO 27002 Controls:**
|
||||
- **Control 5.30 – ICT Readiness for Business Continuity:** Ensures backup and recovery plans are in place to restore data and operations.
|
||||
- **Control 8.7 – Protection Against Malware:** Focuses on deploying anti-malware solutions and user awareness training.
|
||||
- **Attribute Application:** Controls are tagged with attributes like *confidentiality*, *availability*, *operational capability: recovery*, and *control type: preventive/detective* to ensure comprehensive coverage for ransomware scenarios[3][4].
|
||||
|
||||
#### Example 2: Physical Intrusion Scenario
|
||||
|
||||
- **Event:** Unauthorized individual gains access to a secure server room.
|
||||
- **Consequence:** Potential theft, tampering, or destruction of critical IT infrastructure.
|
||||
- **Relevant ISO 27002 Controls:**
|
||||
- **Control 7.4 – Physical Security Monitoring:** Involves surveillance, alarms, and access controls.
|
||||
- **Attribute Application:** Controls are assigned attributes such as *security domain: physical*, *control type: preventive*, and *information security property: integrity/availability* to address physical threats[4].
|
||||
|
||||
#### Example 3: Data Breach Due to Weak Passwords
|
||||
|
||||
- **Event:** Attacker exploits weak passwords to access sensitive customer data.
|
||||
- **Consequence:** Loss of confidentiality, regulatory fines, and reputational damage.
|
||||
- **Relevant ISO 27002 Controls:**
|
||||
- **Control 8.2 – Privileged Access Rights:** Ensures strong authentication for sensitive accounts.
|
||||
- **Control 8.3 – User Registration and De-registration:** Manages user access lifecycle.
|
||||
- **Attribute Application:** Controls are mapped with attributes like *confidentiality*, *control type: preventive*, and *cybersecurity concept: access control* to strengthen defenses against this scenario[1][2].
|
||||
|
||||
### Practical Benefits
|
||||
|
||||
- **Gap Analysis:** By mapping controls and attributes to specific scenarios, organizations can more easily identify coverage gaps in their risk treatment plans.
|
||||
- **Customization:** Attributes can be tailored to reflect unique operational needs, such as department, asset type, or implementation status.
|
||||
- **Resilience Assessment:** The method helps organizations test their resilience to control failures by simulating real-world events and consequences[1][2].
|
||||
|
||||
This scenario-driven approach grounds the selection and customization of controls in realistic threats, making the information security framework more robust and relevant to the organization's actual risk landscape.
|
||||
|
||||
Sources
|
||||
[1] Alireza Ghahrood - Guidance on ISO/IEC 27002 Attributes - LinkedIn https://www.linkedin.com/posts/alirezaghahrood_iso-27028-guidance-on-isoiec-27002-attributes-activity-7302656222434877441-X94G
|
||||
[2] [PDF] Control attributes - ISO 27001 Security https://www.iso27001security.com/SecAware_white_paper_on_security_control_attributes_v2_1_.pdf
|
||||
[3] The two approaches for information security risk identification ... https://rigcert.education/resources/the-approaches-for-information-security-risk-identification-according-to-iso-27005
|
||||
[4] ISO 27002 Essentials: A Comprehensive Overview - NordLayer https://nordlayer.com/learn/iso/iso-27002/
|
||||
[5] ISO 27001 Learning From Information Security Incidents: Annex A 5.27 https://hightable.io/iso-27001-annex-a-5-27-learning-from-information-security-incidents/
|
||||
[6] ISO/IEC TS 27028 Control attributes https://www.iso27001security.com/html/27028.html
|
||||
[7] #iso27001 #isms #iso27002 | Dipen Das, CISM, CISSP, CRISC https://www.linkedin.com/posts/dipendas1979_iso27001-isms-iso27002-activity-7300514829008613376-Vrs6
|
||||
[8] ISO 27002:2022 – Control 6.8 – Information Security Event Reporting https://www.isms.online/iso-27002/control-6-8-information-security-event-reporting/
|
||||
[9] ISO 27001 Attributes Explained Simply - High Table https://hightable.io/iso-27001-attributes-the-ultimate-guide/
|
||||
[10] Guidance on ISO/IEC 27002 attributes https://www.iso.org/obp/ui/en/
|
||||
[11] [PDF] Control attributes - ISO 27001 Security https://www.iso27001security.com/ISO27k_ISMS_6.1_guideline_on_security_control_attributes_2022.pdf
|
||||
[12] ISO 27002:2022 – Control 8.25 – Secure Development Life Cycle https://www.isms.online/iso-27002/control-8-25-secure-development-life-cycle/
|
||||
[13] [PDF] sc27 committee document 11: 2024 (1) - Introduction https://committee.iso.org/files/live/sites/jtc1sc27/files/resources/SC27%20COMMITTEE%20DOCUMENT%2011.pdf
|
||||
[14] ISO 27002:2022, Security Controls. Complete Overview - ISMS.online https://www.isms.online/iso-27002/
|
||||
[15] [PDF] Untitled http://clean-ecology.com/Upload/files/39431062656.pdf
|
||||
[16] XM The ISO 27000 Family of Standards 230516 | PDF - Scribd https://www.scribd.com/document/698051303/Xm-the-ISO-27000-Family-of-Standards-230516
|
||||
[17] ISO27002:2022 explained – Technological controls - ICT Institute https://ictinstitute.nl/iso270022022-explained-technological-controls/
|
||||
[18] ISO/IEC 27005 risk management https://www.iso27001security.com/html/27005.html
|
||||
[19] ISO/IEC 27002:2022(en), Information security, cybersecurity and ... https://www.iso.org/obp/ui/es/
|
||||
[20] ISO/IEC DIS 27028 https://www.iso.org/standard/61007.html
|
||||
|
||||
# Developing a taxonomy of Organization-Specific Attributes
|
||||
|
||||
Developing your taxonomy is a multi-step process that involves gathering information, brainstorming, refining, and validating. The goal is to create a set of labels (attributes) that allow you to slice, dice, and view your security controls from multiple, meaningful perspectives.
|
||||
|
||||
### **Step 1: Gather Foundational Inputs**
|
||||
|
||||
Before you can define custom attributes, you must understand the landscape they need to describe. This involves collecting and analyzing key organizational documents. Think of this as gathering your raw materials.
|
||||
|
||||
- **Risk Register:** This is your most important input. It tells you what you’re trying to protect against. Your attributes should help you select controls that directly mitigate your top risks.
|
||||
|
||||
- **Asset Inventory:** You need to know what you're protecting. A good inventory will classify assets by type (e.g., servers, laptops, cloud services) and criticality.
|
||||
|
||||
- **Business Process Maps:** How does the organization create value? Understanding critical processes (like payment processing or patient data management) helps you link controls directly to business operations.
|
||||
|
||||
- **Compliance Requirements:** Create a master list of all legal, regulatory, and contractual obligations (e.g., GDPR, PCI DSS, HIPAA, client contracts). Your attributes must be able to flag controls needed for compliance.
|
||||
|
||||
- **Stakeholder Analysis:** Identify the people involved with controls: **owners** (accountable for the risk), **implementers** (responsible for building/configuring the control), and **assessors** (who monitor effectiveness).
|
||||
|
||||
|
||||
### **Step 2: Start with the Standard, then Customize**
|
||||
|
||||
Don't reinvent the wheel entirely. ISO/IEC 27002:2022 provides five default attributes that offer a great starting point. Understand them first, then build upon them.
|
||||
|
||||
- **ISO 27002 Default Attributes:**
|
||||
|
||||
- **Control types:** (e.g., #preventive, #detective, #corrective) - _When_ the control acts in relation to a security incident.
|
||||
|
||||
- **Information security properties:** (e.g., #confidentiality, #integrity, #availability) - _What_characteristic of information the control protects.
|
||||
|
||||
- **Cybersecurity concepts:** (e.g., #identify, #protect, #detect, #respond, #recover) - _How_ the control maps to cybersecurity incident management capabilities.
|
||||
|
||||
- **Operational capabilities:** (e.g., #governance, #asset_management) - _Which_ practical security function the control belongs to.
|
||||
|
||||
- **Security domains:** (e.g., #governance_and_ecosystem, #protection, #defence, #resilience) - A high-level categorization of the control's purpose.
|
||||
|
||||
|
||||
Now, based on your Step 1 inputs, brainstorm **organization-specific attributes** that add the context your organization needs.
|
||||
|
||||
- **Brainstorming Categories:**
|
||||
|
||||
- **Business Context:** To link controls to operations.
|
||||
|
||||
- _Examples:_ `Business Unit` (e.g., Finance, HR, R&D), `Applicable Business Process` (e.g., Payroll, Client Onboarding), `Strategic Objective Supported`.
|
||||
|
||||
- **Asset & Data Context:** To link controls to what they protect.
|
||||
|
||||
- _Examples:_ `Asset Type` (e.g., Cloud Database, User Endpoint, OT Sensor), `Data Classification`(e.g., Public, Internal, Confidential).
|
||||
|
||||
- **Compliance Context:** To streamline audits and reporting.
|
||||
|
||||
- _Examples:_ `Applicable Regulation` (e.g., GDPR, CCPA, SOX), `Audit Target` (e.g., Internal Audit Q3, External Pen Test).
|
||||
|
||||
- **Responsibility Context:** To clarify ownership. 🤝
|
||||
|
||||
- _Examples:_ `Control Owner` (e.g., Director of IT, Head of HR), `Implementation Team` (e.g., Network Ops, Cloud Engineering).
|
||||
|
||||
- **Implementation Context:** To manage the control lifecycle.
|
||||
|
||||
- _Examples:_ `Implementation Status` (e.g., Implemented, Planned, Not Started), `Automation Level`(e.g., Manual, Automated, Hybrid).
|
||||
|
||||
|
||||
### **Step 3: Define a Controlled Vocabulary**
|
||||
|
||||
For each attribute, you must define a specific, limited set of possible values. This is crucial for consistency and reporting. Free-text fields are the enemy of a clean taxonomy.
|
||||
|
||||
This is the difference between:
|
||||
|
||||
- **Bad (Free Text):** `Applicable Regulation` = "That EU privacy law"
|
||||
|
||||
- **Good (Controlled Vocabulary):** `Applicable Regulation` = `GDPR`
|
||||
|
||||
|
||||
**Example Attribute & Value Set:**
|
||||
|
||||
|Attribute|Controlled Values|Description|
|
||||
|---|---|---|
|
||||
|**Data Classification**|`Public`, `Internal`, `Confidential`, `Restricted`|The sensitivity level of data the control protects.|
|
||||
|**Implementation Status**|`Planned`, `In Progress`, `Implemented`, `Retired`|The current lifecycle stage of the control.|
|
||||
|**Automation Level**|`Manual`, `Hybrid`, `Fully Automated`|The degree to which the control operates without human intervention.|
|
||||
|
||||
### **Step 4: Review, Refine, and Validate**
|
||||
|
||||
Assemble a working group of the stakeholders you identified in Step 1 (IT, security, legal, business representatives). Present your draft taxonomy and ask critical questions:
|
||||
|
||||
- **Is it useful?** Will this attribute help us make better risk decisions or select controls more easily?
|
||||
|
||||
- **Is it clear?** Is the meaning of the attribute and its values unambiguous?
|
||||
|
||||
- **Is it sustainable?** Can we realistically and consistently apply these attributes to our controls?
|
||||
|
||||
- **Is it lean?** Are there redundant attributes? Can we combine any? Avoid "analysis paralysis" by keeping the taxonomy as simple as possible while still being effective.
|
||||
|
||||
|
||||
The output of this step is a validated and agreed-upon taxonomy, ready for documentation.
|
||||
|
||||
---
|
||||
|
||||
By following these steps, you create a rich, multi-faceted taxonomy. This allows anyone in the organization—from a CISO wanting a high-level view of risk mitigation to an engineer selecting controls for a new system—to filter and understand security controls through a lens that is directly relevant to their role and responsibilities.
|
||||
|
||||
85
Corpus/Standards/ISO27x/about/ISO 27034 MoC.md
Normal file
85
Corpus/Standards/ISO27x/about/ISO 27034 MoC.md
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
---
|
||||
tags:
|
||||
- iso27034
|
||||
- type/MoC
|
||||
---
|
||||
# ISO 27034 Application security
|
||||
|
||||
|
||||
[Overview by SecAware](https://www.iso27001security.com/html/27034.html)
|
||||
|
||||
## Overview generated by Gemini
|
||||
|
||||
These ISO/IEC standards establish comprehensive frameworks for **application security**, aiming to ensure software is built and maintained securely throughout its lifecycle. **ISO/IEC 27034-1** introduces core concepts like the **Organization Normative Framework (ONF)**, a central repository for reusable security elements, and **Application Security Controls (ASCs)**, which detail security activities and their verification. **ISO/IEC 27034-2** provides the **organizational framework** for managing the ONF, detailing its components such as business, regulatory, and technological contexts, along with processes like risk analysis and verification. **ISO/IEC 27034-3** outlines the **Application Security Management Process (ASMP)**, guiding organizations in integrating security into each application's lifecycle, from specifying requirements to auditing. Finally, **ISO/IEC 27034-6** offers **case studies and examples**, illustrating the practical application of ASCs and the **Application Security Life Cycle Reference Model (ASLCRM)**, while **ISO/IEC 27034-7** introduces the concept of **Prediction Application Security Rationales (PASRs)** for assessing the security of subsequent application versions without full re-verification.
|
||||
|
||||
The ISO/IEC 27034 series provides a comprehensive framework to **integrate security seamlessly throughout the life cycle of applications**. It is designed to assist organizations in protecting their information at the application level and applies to applications developed in-house, acquired from third parties, or outsourced. Importantly, it is applicable to organizations of all sizes and types, including commercial enterprises and government agencies. It is not a software application development standard, a project management standard, or a software development life cycle standard itself, but rather integrates with existing processes.
|
||||
|
||||
The purpose of ISO/IEC 27034 is to help organizations:
|
||||
|
||||
• Establish **security requirements** and **assess security risks**.
|
||||
• Assign a **Targeted Level of Trust** to applications and select corresponding security controls and verification measures.
|
||||
• Demonstrate that their applications can be used securely under a defined environment.
|
||||
• Support the general concepts of ISO/IEC 27001 (Information security management systems) and implement security controls from ISO/IEC 27002 (Code of practice for information security management).
|
||||
• **Minimize resistance to changes** brought by new application security elements.
|
||||
• **Standardize application security elements** for uniform implementation and verification.
|
||||
• Achieve an appropriate level of security in a **cost-effective manner**, for example, through reusing existing approved application security elements.
|
||||
|
||||
**Overview of the 27034 Framework**
|
||||
|
||||
The ISO/IEC 27034 framework is built around two main overarching processes:
|
||||
|
||||
1. **Organization Normative Framework (ONF) Management Process**: This is a **continuous, organizational-level process** responsible for managing the application security aspects of the ONF. It defines and maintains the organization's contexts for application security and serves as a central reference.
|
||||
|
||||
2. **Application Security Management Process (ASMP)**: This process is used for **managing security on specific application projects**. It is a specialization of the risk management process found in ISO/IEC 27005. The ASMP helps a project team apply relevant portions of the ONF to a specific application project and formally record evidence of the outcomes in an Application Normative Framework (ANF).
|
||||
|
||||
**Key Components and Concepts**
|
||||
|
||||
To implement these processes, ISO/IEC 27034 introduces several core components:
|
||||
|
||||
• **Organization Normative Framework (ONF)**: The **most important component** of ISO/IEC 27034, the ONF is an **organization-wide framework** that stores all application security best practices recognized by the organization. It acts as the foundation for application security, guiding all future security decisions. Key elements of the ONF include:
|
||||
|
||||
◦ **Business context component**: Identifies security risks and requirements from the organization’s business activities and adopted standards.
|
||||
|
||||
◦ **Regulatory context component**: Identifies security risks from applicable laws and regulations in the countries or jurisdictions where the application is developed, deployed, or used.
|
||||
|
||||
◦ **Technological context component**: Identifies security risks from the organization’s IT components and best practices for their use.
|
||||
|
||||
◦ **Application specifications repository**: Documents general IT functional requirements and pre-approved solutions to determine and mitigate risks from application specifications.
|
||||
|
||||
◦ **Roles, responsibilities and qualifications repository**: Lists all roles, responsibilities, and required qualifications for actors involved with the organization’s applications and ONF.
|
||||
|
||||
◦ **Organization Application Security Control (ASC) Library**: The **repository of all ASCs available in the organization**. ASCs are associated with one or many levels of trust.
|
||||
|
||||
◦ **Application Security Life Cycle Reference Model (ASLCRM)**: A reference model that helps to uniformly identify and communicate _when_ in the application life cycle and _by whom_ ASCs should be implemented. It is divided into Provisioning (Preparation, Realization, Transition) and Operation (Utilization and maintenance, Archival, Destruction) stages, and vertically into layers like Application management, Application provisioning and operation, Infrastructure management, and Application audit.
|
||||
|
||||
• **Application Security Control (ASC)**: A **central concept** in ISO/IEC 27034, an ASC is a data structure that precisely describes a **security activity** and its associated **verification measurement** to be performed at a specific point in an application's life cycle. It formalizes security activities and ensures supporting evidence is collected for verification.
|
||||
|
||||
• **Application Normative Framework (ANF)**: A **subset or refinement of the ONF** that contains only the detailed, relevant information required for a **specific application project** to achieve its Targeted Level of Trust. Its security requirements are derived from the application's risk assessment.
|
||||
|
||||
• **Levels of Trust (LoT)**: A label identifying a set of applicable ASCs from the Organization ASC Library.
|
||||
|
||||
◦ **Targeted Level of Trust (TLOT)**: The set of ASCs deemed necessary by the application owner to lower the risk associated with a specific application to an acceptable level. This becomes the goal for the application project team.
|
||||
|
||||
◦ **Actual Level of Trust (ALOT)**: The maximum confidence level demonstrated by the verification team based on the verification measurements of all the application’s ASCs. An application is considered **"secure"** when its Actual Level of Trust is equal to or greater than its Targeted Level of Trust.
|
||||
|
||||
**Implementation in a Small Software Development Company**
|
||||
|
||||
For a small software development company, implementing ISO/IEC 27034 can be approached effectively by leveraging its inherent flexibility and iterative nature:
|
||||
|
||||
• **Integration with Existing Processes**: The processes and frameworks of ISO/IEC 27034 are designed to be **integrated into an organization's existing processes**, rather than implemented in isolation. This means your company can map its current software development lifecycle and practices to the ISO/IEC 27034 framework, reducing the impact of adopting new standards.
|
||||
|
||||
• **Iterative Implementation**: The ONF Management Process should be performed **iteratively**, allowing you to implement the ONF incrementally. This approach helps to **reduce initial impact** and achieve quicker gains by prioritizing the elements that are most urgently needed for your company. You can start with a baseline level of security and expand as your needs and resources grow.
|
||||
|
||||
• **Focus on Core Components**: For a small company, it might be beneficial to initially focus on formalizing the most critical ONF components, such as the **business, regulatory, and technological contexts**, and developing a foundational **ASC Library** relevant to your primary applications.
|
||||
|
||||
• **Defined Roles and Responsibilities**: While RACI charts are mentioned, the standard emphasizes that organizations should align guidance with their own methods for clarifying roles and responsibilities. This allows for flexibility in how a small team defines who is "responsible," "accountable," "consulted," and "informed" for application security activities.
|
||||
|
||||
• **Cost-Effectiveness and Reuse**: A key purpose of the ONF is to enable an appropriate level of security in a **cost-effective manner**, for instance, by **reusing existing approved application security elements**. This is a significant advantage for a small company where resource optimization is crucial. Once ASCs are defined, they can be reused across multiple projects.
|
||||
|
||||
• **Leveraging Automation and Tools**: The standard encourages the use of approved tools to take advantage of new security analysis functionality. Automation can increase consistency in defining and enforcing security requirements and Targeted Levels of Trust across applications. This can be particularly beneficial for a small team, enabling them to achieve more with fewer manual efforts.
|
||||
|
||||
• **Targeted Level of Trust for Each Application**: By defining a **Targeted Level of Trust** for each application based on a risk assessment, your company can ensure that the investment in security is appropriate for the value and risks associated with that specific application.
|
||||
|
||||
• **Guidance for Acquisition/Outsourcing**: If your company acquires software or outsources development, ISO/IEC 27034 provides guidelines for communicating requirements and verifying evidence of security controls from third parties.
|
||||
|
||||
By systematically implementing the framework, even in a simplified and iterative manner, your small software development company can gain demonstrable evidence that its applications are adequately protected, align with industry best practices, and improve its overall application security posture.
|
||||
3
Corpus/Standards/ISO27x/about/ISO 27034-5.md
Normal file
3
Corpus/Standards/ISO27x/about/ISO 27034-5.md
Normal file
|
|
@ -0,0 +1,3 @@
|
|||
# ISO 27034-5 Protocols and application security control data structure
|
||||
|
||||
|
||||
5
Corpus/Standards/ISO27x/about/ISO 27701.md
Normal file
5
Corpus/Standards/ISO27x/about/ISO 27701.md
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
# ISO 27701 Privacy information management Requirements and guidelines
|
||||
|
||||
|
||||
|
||||
|
||||
54
Corpus/Standards/ISO27x/about/ISO 27k standards overview.md
Normal file
54
Corpus/Standards/ISO27x/about/ISO 27k standards overview.md
Normal file
|
|
@ -0,0 +1,54 @@
|
|||
---
|
||||
tags:
|
||||
- iso27001
|
||||
- iso27002
|
||||
- type/MoC
|
||||
- nen7510
|
||||
---
|
||||
# ISO and NEN security standards
|
||||
## ISO 27001 & 27002
|
||||
|
||||
Indexes:
|
||||
- [ISO 27001:2022 EN](ISO_27001_2022_Index.md)
|
||||
- [ISO 27002:2022 EN](ISO_27001_2022_Index%20EXT.md) – Includes references to 2013 version!
|
||||
- [ISO 27001:2023 NL](../OST/ISO_27001_2023_NL_Index.md)
|
||||
- [ISO 27002:2022 NL](../OST/ISO_27002_2022_NL_Index.md)
|
||||
- [Vertaaltabel Engels-Nederlands](ISO_27002_2022_Vertaaltabel_Engels_Nederlands.md)
|
||||
|
||||
EN source tekst:
|
||||
- ISO 27001:2022 [PDF](../OST/27001/EN/ISO_27001_2022_EN.pdf)
|
||||
- ISO 27002:2022 [PDF](../OST/27002/EN/ISO_27002_2022_EN.pdf)
|
||||
|
||||
NL brontekst:
|
||||
- ISO 27001:2023 [PDF](OST/27001/NL/ISO_27001_2023_NL_PDF.md)
|
||||
- ISO 27002:2022 [PDF](../OST/ISO_27002_2022_NL_PDF.md)
|
||||
|
||||
|
||||
See also:
|
||||
- [Plain English ISO IEC 27002 2005 from Praxiom](https://www.praxiom.com/iso-17799-objectives.htm)
|
||||
- [Changes in ISO 27001:2022 (table)](../OST/27001/Detailed%20comparison%20between%202017%20and%202022.md)
|
||||
- [[ISO 27002 2022 What's New]]
|
||||
- [ISO_27001_2023_NL_Aanpassingen](../OST/ISO_27001_2023_NL_Aanpassingen.md)
|
||||
- [Changes in ISO 27001_2022_Advisera](../../../../iso27DIY-gis/reference/Changes%20in%20ISO%2027001_2022_Advisera.md)
|
||||
- [IBB op hoofdlijnen](../OST/IBB%20op%20hoofdlijnen.md)
|
||||
- [ISO 27001 2023 Processen en Artefacten](../OST/ISO%2027001%202023%20Processen%20en%20Artefacten.md)
|
||||
- [Advised Documents for ISO 27001](../../../../iso27DIY-gis/reference/Advised%20Documents%20for%20ISO%2027001.md)
|
||||
- [Types of Controls](Types%20of%20Controls.md)
|
||||
|
||||
Depreciated:
|
||||
[ISO_27001_2013_EN_Index](../legacy/ISO%2027001%202013/ISO_27001_2013_EN_Index.md)
|
||||
[ISO_27001_2017_NL_Index](../legacy/ISO%2027001%202017%20NL/ISO_27001_2017_NL_Index.md)
|
||||
|
||||
## Related ISO standards
|
||||
- [ISO 27k family](../../../../iso27DIY-gis/reference/Examples/ISO%2027k%20family.md)
|
||||
- [ISO 27000](ISO%2027000%20MoC.md)
|
||||
- [ISO 27005](ISO%2027005.md)
|
||||
- NEN 7510
|
||||
- [NEN 7510-1:2024](../OST/7510/NEN7510_2024_NL_1.md)
|
||||
- [NEN 7510-2:2024](../OST/7510/NEN7510_2024_NL_2.md)
|
||||
- [NEN 7510-1:2024 Bijlage A](../OST/7510/NEN7510_2024_NL_1_A.md)
|
||||
- [NEN 7510-1:2024 Bijlage B](../OST/7510/NEN7510_2024_NL_1_B.md)
|
||||
- [NEN 7510-1:2024 Bijlage C](../OST/7510/NEN7510_2024_NL_1_C.md)
|
||||
- [NEN 7510-1:2024 vs. ISO 27001:2022](../OST/7510/NEN%207510%20vs%20ISO%2027001.md)
|
||||
- [Lijst met relevante risico's](../OST/7510/NEN7510%20Risicos.md)
|
||||
|
||||
|
|
@ -0,0 +1,78 @@
|
|||
# ISO Certification: Structure and Process
|
||||
|
||||
**ISO (International Organization for Standardization) does not itself certify organizations or offer certification services.** Instead, a structured, multi-level system involving independent third parties is used to ensure that organizations can be recognized as “ISO-certified” for implementing ISO standards[^4][^6].
|
||||
### **Key Elements of the ISO Certification Construction**
|
||||
|
||||
- **ISO Develops Standards, Not Certification**
|
||||
- ISO’s role is to develop international standards (such as ISO 9001 for quality management), but it does not perform certification or issue certificates[^4][^6].
|
||||
- The ISO logo cannot be used to indicate certification, and ISO does not authorize anyone to use its logo for this purpose[^4].
|
||||
|
||||
- **Certification Bodies**
|
||||
- Certification is performed by independent organizations known as *certification bodies* (sometimes called registrars)[^2][^3][^6].
|
||||
- These bodies are responsible for auditing organizations to assess whether their management systems, products, or services comply with specific ISO standards[^2][^3].
|
||||
- If the organization meets the requirements, the certification body issues a certificate confirming compliance[^2][^3].
|
||||
|
||||
- **Accreditation Bodies**
|
||||
- To ensure certification bodies themselves operate competently and impartially, they are accredited by *accreditation bodies*—usually one per country[^5][^6].
|
||||
- Accreditation bodies evaluate and formally recognize certification bodies according to international standards, most notably ISO/IEC 17021 for management system certification[^5][^6].
|
||||
- Accreditation provides assurance that the certification process is credible and internationally recognized[^5][^6].
|
||||
|
||||
- **International Oversight**
|
||||
- International organizations such as the International Accreditation Forum (IAF) and the International Laboratory Accreditation Cooperation (ILAC) oversee and harmonize the activities of accreditation bodies to ensure global consistency and mutual recognition of certificates[^4][^5][^6].
|
||||
|
||||
|
||||
### **Certification Process Overview**
|
||||
|
||||
The typical steps for an organization to become ISO-certified are:
|
||||
|
||||
1. **Develop and Implement the Management System**
|
||||
- The organization designs and implements a management system that meets the chosen ISO standard’s requirements[^1][^3][^7].
|
||||
2. **Internal Audit and Review**
|
||||
- The organization conducts internal audits and management reviews to ensure compliance and effectiveness[^3][^7].
|
||||
3. **Select an Accredited Certification Body**
|
||||
- The organization chooses an independent, accredited certification body to conduct the external audit[^3][^4].
|
||||
4. **External Audit**
|
||||
- The certification body performs a thorough audit (often in two stages) to verify compliance with the ISO standard[^2][^3].
|
||||
5. **Certification Decision**
|
||||
- If the audit is successful, the certification body issues an ISO certificate, typically valid for three years, subject to periodic surveillance audits[^2][^3].
|
||||
|
||||
### **Summary Table: ISO Certification Structure**
|
||||
|
||||
| Role | Function |
|
||||
| :---------------------- | :------------------------------------------------------------------------------- |
|
||||
| ISO | Develops standards; does not certify organizations |
|
||||
| Certification Body | Audits organizations and issues certificates if compliant |
|
||||
| Accreditation Body | Accredits certification bodies to ensure competence and impartiality |
|
||||
| International Oversight | IAF/ILAC harmonize accreditation globally for mutual recognition of certificates |
|
||||
|
||||
### **Key Points**
|
||||
|
||||
- ISO does not certify organizations; certification is performed by independent, accredited certification bodies[^4][^6].
|
||||
- Certification bodies are themselves accredited by national or regional accreditation bodies, ensuring their competence and impartiality[^5][^6].
|
||||
- Accreditation bodies operate under international oversight to maintain global consistency[^4][^5][^6].
|
||||
- The ISO recognizes the system of certification and accreditation but does not issue certificates itself[^4][^6].
|
||||
|
||||
This system ensures that ISO certification is credible, impartial, and internationally recognized, even though ISO itself is not directly involved in certifying organizations.
|
||||
|
||||
---
|
||||
|
||||
[^1]: https://www.indeed.com/career-advice/career-development/what-is-iso-certifications
|
||||
[^2]: https://www.iso-certification-qatar.com/iso-9001-certification-body.html
|
||||
[^3]: https://www.9001simplified.com/learn/iso-9001-certification-steps.php
|
||||
[^4]: https://www.iso.org/certification.html
|
||||
[^5]: https://certiget.eu/en/guides/guide-iso-17021-accreditation-bodies
|
||||
[^6]: https://info.degrandson.com/blog/accreditation-certification
|
||||
[^7]: https://iso-specialist.com/iso-certification-explained/
|
||||
[^8]: https://bizmasterz.com/what-role-of-certification-body/
|
||||
[^9]: https://www.dnv.com/assurance/articles/iso-accreditation-vs-iso-certification/
|
||||
[^10]: https://business.gov.nl/products-services-and-innovation/orders-and-tenders/iso-and-nen-certification-for-your-business/
|
||||
[^11]: https://www.kiwa.com/en/service2/certification/iso-9001-quality-management-systems-certification/
|
||||
[^12]: https://www.qmsuk.com/iso-by-industry/construction
|
||||
[^13]: https://www.siscertifications.com/construction/
|
||||
[^14]: https://www.linkedin.com/pulse/how-iso-certification-work-atul-kumar-jvg9c
|
||||
[^15]: https://www.bdc.ca/en/articles-tools/operations/iso-other-certifications/iso-certificate-process
|
||||
[^16]: https://www.iso-9001-checklist.co.uk/what-are-the-steps-for-iso-certification.htm
|
||||
[^17]: http://www.b-advancy.com/blog/how-to-achieve-iso-certification-in-the-construction-industry
|
||||
[^18]: https://secureframe.com/hub/iso-27001/certification-process
|
||||
[^19]: https://www.irqs.co.in/iso-certification-for-construction-key-standards-and-compliance-requirements/
|
||||
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
|
@ -0,0 +1,28 @@
|
|||
#iso31000/2018
|
||||
|
||||
### 5.4.1 Understanding the organization and its context
|
||||
From ISO 31000:2018
|
||||
|
||||
When designing the framework for managing risk, the organization should examine and understand its external and internal context.
|
||||
|
||||
Examining the organization’s **external context** may include, but is not limited to:
|
||||
|
||||
- the social, cultural, political, legal, regulatory, financial, technological, economic and environmental factors, whether international, national, regional or local;
|
||||
- key drivers and trends affecting the objectives of the organization;
|
||||
- external stakeholders’ relationships, perceptions, values, needs and expectations;
|
||||
- contractual relationships and commitments;
|
||||
- the complexity of networks and dependencies.
|
||||
|
||||
|
||||
Examining the organization’s **internal context** may include, but is not limited to:
|
||||
|
||||
- vision, mission and values;
|
||||
- governance, organizational structure, roles and accountabilities;
|
||||
- strategy, objectives and policies;
|
||||
- the organization’s culture;
|
||||
- standards, guidelines and models adopted by the organization;
|
||||
- capabilities, understood in terms of resources and knowledge (e.g. capital, time, people, intellectual property, processes, systems and technologies);
|
||||
- data, information systems and information flows;
|
||||
- relationships with internal stakeholders, taking into account their perceptions and values;
|
||||
- contractual relationships and commitments;
|
||||
- interdependencies and interconnections.
|
||||
File diff suppressed because one or more lines are too long
113
Corpus/Standards/ISO27x/about/ISO_27001_2022_Index EXT.md
Normal file
113
Corpus/Standards/ISO27x/about/ISO_27001_2022_Index EXT.md
Normal file
|
|
@ -0,0 +1,113 @@
|
|||
#iso27002/2022/EN
|
||||
# ISO 27002:2022 EN Index
|
||||
|
||||
| 2022 ID | Control title | 2013 |
|
||||
| ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
|
||||
| **F** | **[[ISO_27002_OT_F Foreword \|Foreword]]** | |
|
||||
| **0** | **[[ISO_27002_OT_0 Introduction \|Introduction]]** | |
|
||||
| **1** | **[[ISO_27002_OT_1 Scope \|Scope]]** | |
|
||||
| **2** | **[[ISO_27002_OT_2 Normative references\|Normative references]]** | |
|
||||
| **3** | **Terms, definitions and abbreviated terms** | |
|
||||
| 3.1 | **[[ISO_27002_OT_3.1 Terms and definitions\|Terms and definitions]]** | |
|
||||
| 3.2 | **[[ISO_27002_OT_3.2 Abbreviated terms\|Abbreviated terms]]** | |
|
||||
| **4** | **Structure of this document** | |
|
||||
| 4.1 | [[ISO_27002_OT_4.1 Clauses \| Clauses ]] | |
|
||||
| 4.2 | [[ISO_27002_OT_4.2 Themes and attributes \| Themes and attributes ]] | |
|
||||
| 4.3 | [[ISO_27002_OT_4.3 Control layout \| Control layout ]] | |
|
||||
| **5** | **Organizational controls** | |
|
||||
| 5.1 | [Policies for information security ](../legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md) | 05.1.1, 05.1.2 |
|
||||
| 5.2 | [Information security roles and responsibilities ](../../MoCs/ISO_27002_2022_5.2_MoC%20Information%20security%20roles%20and%20responsibilities.md) | 06.1.1 |
|
||||
| 5.3 | [Segregation of duties ](../../MoCs/ISO_27002_2022_5.3_MoC%20Segregation%20of%20duties.md) | 06.1.2 |
|
||||
| 5.4 | [Management responsibilities ](../../MoCs/ISO_27002_2022_5.4_MoC%20Management%20responsibilities.md) | 07.2.1 |
|
||||
| 5.5 | [Contact with authorities ](../../MoCs/ISO_27002_2022_5.5_MoC%20Contact%20with%20authorities.md) | 06.1.3 |
|
||||
| 5.6 | [Contact with special interest groups ](../../MoCs/ISO_27002_2022_5.6_MoC%20Contact%20with%20special%20interest%20groups.md) | 06.1.4 |
|
||||
| 5.7 | [Threat intelligence ](../../MoCs/ISO_27002_2022_5.7_MoC%20Threat%20intelligence.md) | New |
|
||||
| 5.8 | [Information security in project management ](../../MoCs/ISO_27002_2022_5.8_MoC%20Information%20security%20in%20project%20management.md) | 06.1.5, 14.1.1 |
|
||||
| 5.9 | [Inventory of information and other associated assets ](../../MoCs/ISO_27002_2022_5.9_MoC%20Inventory%20of%20information%20and%20other%20associated%20assets.md) | 08.1.1, 08.1.2 |
|
||||
| 5.10 | [Acceptable use of information and other associated assets ](../../MoCs/ISO_27002_2022_5.10_MoC%20Acceptable%20use%20of%20information%20and%20other%20associated%20assets.md) | 08.1.3, 08.2.3 |
|
||||
| 5.11 | [Return of assets ](../../MoCs/ISO_27002_2022_5.11_MoC%20Return%20of%20assets.md) | 08.1.4 |
|
||||
| 5.12 | [Classification of information ](../../MoCs/ISO_27002_2022_5.12_MoC%20Classification%20of%20information.md) | 08.2.1 |
|
||||
| 5.13 | [Labelling of information ](../../MoCs/ISO_27002_2022_5.13_MoC%20Labelling%20of%20information.md) | 08.2.2 |
|
||||
| 5.14 | [Information transfer ](../../MoCs/ISO_27002_2022_5.14_MoC%20Information%20transfer.md) | 13.2.1, 13.2.2, 13.2.3 |
|
||||
| 5.15 | [Access control ](../../MoCs/ISO_27002_2022_5.15_MoC%20Access%20control.md) | 09.1.1, 09.1.2 |
|
||||
| 5.16 | [Identity management ](../../MoCs/ISO_27002_2022_5.16_MoC%20Identity%20management.md) | 09.2.1 |
|
||||
| 5.17 | [Authentication information ](../../../Information%20Security/Authentication%20information.md) | 09.2.4, 09.3.1, 09.4.3 |
|
||||
| 5.18 | [Access rights ](../../MoCs/ISO_27002_2022_5.18_MoC%20Access%20rights.md) | 09.2.2, 09.2.5, 09.2.6 |
|
||||
| 5.19 | [Information security in supplier relationships ](../../MoCs/ISO_27002_2022_5.19_MoC%20Information%20security%20in%20supplier%20relationships.md) | 15.1.1 |
|
||||
| 5.20 | [Addressing information security within supplier agreements ](../../MoCs/ISO_27002_2022_5.20_MoC%20Addressing%20information%20security%20within%20supplier%20agreements.md) | 15.1.2 |
|
||||
| 5.21 | [Managing information security in the ICT supply chain ](../../MoCs/ISO_27002_2022_5.21_MoC%20Managing%20information%20security%20in%20the%20ICT%20supply%20chain.md) | 15.1.3 |
|
||||
| 5.22 | [Monitoring, review and change management of supplier services ](../../MoCs/ISO_27002_2022_5.22_MoC%20Monitoring,%20review%20and%20change%20management%20of%20supplier%20services.md) | 15.2.1, 15.2.2 |
|
||||
| 5.23 | [Information security for use of cloud services ](../../MoCs/ISO_27002_2022_5.23_MoC%20Information%20security%20for%20use%20of%20cloud%20services.md) | New |
|
||||
| 5.24 | [Information security incident management planning and preparation ](../../MoCs/ISO_27002_2022_5.24_MoC%20Information%20security%20incident%20management%20planning%20and%20preparation.md) | 16.1.1 |
|
||||
| 5.25 | [Assessment and decision on information security events ](../../MoCs/ISO_27002_2022_5.25_MoC%20Assessment%20and%20decision%20on%20information%20security%20events.md) | 16.1.4 |
|
||||
| 5.26 | [Response to information security incidents ](../../MoCs/ISO_27002_2022_5.26_MoC%20Response%20to%20information%20security%20incidents.md) | 16.1.5 |
|
||||
| 5.27 | [Learning from information security incidents ](../../MoCs/ISO_27002_2022_5.27_MoC%20Learning%20from%20information%20security%20incidents.md) | 16.1.6 |
|
||||
| 5.28 | [Collection of evidence ](../../MoCs/ISO_27002_2022_5.28_MoC%20Collection%20of%20evidence.md) | 16.1.7 |
|
||||
| 5.29 | [Information security during disruption ](../../MoCs/ISO_27002_2022_5.29_MoC%20Information%20security%20during%20disruption.md) | 17.1.1, 17.1.2, 17.1.3 |
|
||||
| 5.30 | [ICT readiness for business continuity ](../../../Information%20Security/ICT%20readiness%20for%20business%20continuity.md) | New |
|
||||
| 5.31 | [Legal, statutory, regulatory and contractual requirements ](../../MoCs/ISO_27002_2022_5.31_MoC%20Legal,%20statutory,%20regulatory%20and%20contractual%20requirements.md) | 18.1.1, 18.1.5 |
|
||||
| 5.32 | [Intellectual property rights ](../../MoCs/ISO_27002_2022_5.32_MoC%20Intellectual%20property%20rights.md) | 18.1.2 |
|
||||
| 5.33 | [Protection of records ](About%20A-5.33%20Protection%20of%20records.md) | 18.1.3 |
|
||||
| 5.34 | [Privacy and protection of PII ](../../MoCs/ISO_27002_2022_5.34_MoC%20Privacy%20and%20protection%20of%20PII.md) | 18.1.4 |
|
||||
| 5.35 | [Independent review of information security ](../../MoCs/ISO_27002_2022_5.35_MoC%20Independent%20review%20of%20information%20security.md) | 18.2.1 |
|
||||
| 5.36 | [Compliance with policies, rules and standards for information security](../../MoCs/ISO_27002_2022_5.36_MoC%20Compliance%20with%20policies,%20rules%20and%20standards%20for%20information%20security.md) | 18.2.2, 18.2.3 |
|
||||
| 5.37 | [Documented operating procedures ](../../MoCs/ISO_27002_2022_5.37_MoC%20Documented%20operating%20procedures.md) | 12.1.1 |
|
||||
| **6** | **People controls** | |
|
||||
| 6.1 | [Screening ](../../MoCs/ISO_27002_2022_6.1_MoC%20Screening.md) | 07.1.1 |
|
||||
| 6.2 | [Terms and conditions of employment ](../../MoCs/ISO_27002_2022_6.2_MoC%20Terms%20and%20conditions%20of%20employment.md) | 07.1.2 |
|
||||
| 6.3 | [Information security awareness, education and training ](../../MoCs/ISO_27002_2022_6.3_MoC%20Information%20security%20awareness,%20education%20and%20training.md) | 07.2.2 |
|
||||
| 6.4 | [Disciplinary process ](../../MoCs/ISO_27002_2022_6.4_MoC%20Disciplinary%20process.md) | 07.2.3 |
|
||||
| 6.5 | [Responsibilities after termination or change of employment ](../../MoCs/ISO_27002_2022_6.5_MoC%20Responsibilities%20after%20termination%20or%20change%20of%20employment.md) | 07.3.1 |
|
||||
| 6.6 | [Confidentiality or non-disclosure agreements ](../../MoCs/ISO_27002_2022_6.6_MoC%20Confidentiality%20or%20non-disclosure%20agreements.md) | 13.2.4 |
|
||||
| 6.7 | [Remote working ](../../MoCs/ISO_27002_2022_6.7_MoC%20Remote%20working.md) | 06.2.2 |
|
||||
| 6.8 | [Information security event reporting ](../../MoCs/ISO_27002_2022_6.8_MoC%20Information%20security%20event%20reporting.md) | 16.1.2, 16.1.3 |
|
||||
| **7** | **Physical controls** | |
|
||||
| 7.1 | [Physical security perimeters ](../../MoCs/ISO_27002_2022_7.1_MoC%20Physical%20security%20perimeters.md) | 11.1.1 |
|
||||
| 7.2 | [Physical entry ](../../MoCs/ISO_27002_2022_7.2_MoC%20Physical%20entry.md) | 11.1.2, 11.1.6 |
|
||||
| 7.3 | [Securing offices, rooms and facilities ](../../MoCs/ISO_27002_2022_7.3_MoC%20Securing%20offices,%20rooms%20and%20facilities.md) | 11.1.3 |
|
||||
| 7.4 | [Physical security monitoring ](../../MoCs/ISO_27002_2022_7.4_MoC%20Physical%20security%20monitoring.md) | New |
|
||||
| 7.5 | [Protecting against physical and environmental threats ](../../MoCs/ISO_27002_2022_7.5_MoC%20Protecting%20against%20physical%20and%20environmental%20threats.md) | 11.1.4 |
|
||||
| 7.6 | [Working in secure areas ](../../MoCs/ISO_27002_2022_7.6_MoC%20Working%20in%20secure%20areas.md) | 11.1.5 |
|
||||
| 7.7 | [Clear desk and clear screen ](../../MoCs/ISO_27002_2022_7.7_MoC%20Clear%20desk%20and%20clear%20screen.md) | 11.2.9 |
|
||||
| 7.8 | [Equipment siting and protection ](../../MoCs/ISO_27002_2022_7.8_MoC%20Equipment%20siting%20and%20protection.md) | 11.2.1 |
|
||||
| 7.9 | [Security of assets off-premises ](../../MoCs/ISO_27002_2022_7.9_MoC%20Security%20of%20assets%20off-premises.md) | 11.2.6 |
|
||||
| 7.10 | [Storage media ](../../MoCs/ISO_27002_2022_7.10_MoC%20Storage%20media.md) | 08.3.1, 08.3.2, 08.3.3, 11.2.5 |
|
||||
| 7.11 | [Supporting utilities ](../../MoCs/ISO_27002_2022_7.11_MoC%20Supporting%20utilities.md) | 11.2.2 |
|
||||
| 7.12 | [Cabling security ](../../MoCs/ISO_27002_2022_7.12_MoC%20Cabling%20security.md) | 11.2.3 |
|
||||
| 7.13 | [Equipment maintenance ](../../MoCs/ISO_27002_2022_7.13_MoC%20Equipment%20maintenance.md) | 11.2.4 |
|
||||
| 7.14 | [Secure disposal or re-use of equipment ](../../MoCs/ISO_27002_2022_7.14_MoC%20Secure%20disposal%20or%20re-use%20of%20equipment.md) | 11.2.7 |
|
||||
| **8** | **Technological controls** | |
|
||||
| 8.1 | [User endpoint devices ](../../MoCs/ISO_27002_2022_8.1_MoC%20User%20endpoint%20devices.md) | 06.2.1, 11.2.8 |
|
||||
| 8.2 | [Privileged access rights ](../../MoCs/ISO_27002_2022_8.2_MoC%20Privileged%20access%20rights.md) | 09.2.3 |
|
||||
| 8.3 | [Information access restriction ](About%20Control%208.3%20Information%20access%20restriction.md) | 09.4.1 |
|
||||
| 8.4 | [Access to source code ](../../MoCs/ISO_27002_2022_8.4_MoC%20Access%20to%20source%20code.md) | 09.4.5 |
|
||||
| 8.5 | [Secure authentication ](../../MoCs/ISO_27002_2022_8.5_MoC%20Secure%20authentication.md) | 09.4.2 |
|
||||
| 8.6 | [Capacity management ](../../MoCs/ISO_27002_2022_8.6_MoC%20Capacity%20management.md) | 12.1.3 |
|
||||
| 8.7 | [Protection against malware ](../../MoCs/ISO_27002_2022_8.7_MoC%20Protection%20against%20malware.md) | 12.2.1 |
|
||||
| 8.8 | [Management of technical vulnerabilities ](../../MoCs/ISO_27002_2022_8.8_MoC%20Management%20of%20technical%20vulnerabilities.md) | 12.6.1, 18.2.3 |
|
||||
| 8.9 | [Configuration management ](../../MoCs/ISO_27002_2022_8.9_MoC%20Configuration%20management.md) | New |
|
||||
| 8.10 | [Information deletion ](../../MoCs/ISO_27002_2022_8.10_MoC%20Information%20deletion.md) | New |
|
||||
| 8.11 | [Data masking ](../../MoCs/ISO_27002_2022_8.11_MoC%20Data%20masking.md) | New |
|
||||
| 8.12 | [Data leakage prevention ](../../MoCs/ISO_27002_2022_8.12_MoC%20Data%20leakage%20prevention.md) | New |
|
||||
| 8.13 | [Information backup ](../../MoCs/ISO_27002_2022_8.13_MoC%20Information%20backup.md) | 12.3.1 |
|
||||
| 8.14 | [Redundancy of information processing facilities ](../../MoCs/ISO_27002_2022_8.14_MoC%20Redundancy%20of%20information%20processing%20facilities.md) | 17.2.1 |
|
||||
| 8.15 | [Logging ](../../MoCs/ISO_27002_2022_8.15_MoC%20Logging.md) | 12.4.1, 12.4.2, 12.4.3 |
|
||||
| 8.16 | [Monitoring activities ](../../MoCs/ISO_27002_2022_8.16_MoC%20Monitoring%20activities.md) | New |
|
||||
| 8.17 | [Clock synchronization ](../../MoCs/ISO_27002_2022_8.17_MoC%20Clock%20synchronization.md) | 12.4.4 |
|
||||
| 8.18 | [Use of privileged utility programs ](../../MoCs/ISO_27002_2022_8.18_MoC%20Use%20of%20privileged%20utility%20programs.md) | 09.4.4 |
|
||||
| 8.19 | [Installation of software on operational systems ](../../MoCs/ISO_27002_2022_8.19_MoC%20Installation%20of%20software%20on%20operational%20systems.md) | 12.5.1, 12.6.2 |
|
||||
| 8.20 | [Networks security ](../../MoCs/ISO_27002_2022_8.20_MoC%20Networks%20security.md) | 13.1.1 |
|
||||
| 8.21 | [Security of network services ](../../MoCs/ISO_27002_2022_8.21_MoC%20Security%20of%20network%20services.md) | 13.1.2 |
|
||||
| 8.22 | [Segregation of networks ](../../MoCs/ISO_27002_2022_8.22_MoC%20Segregation%20of%20networks.md) | 13.1.3 |
|
||||
| 8.23 | [Web filtering ](../../MoCs/ISO_27002_2022_8.23_MoC%20Web%20filtering.md) | New |
|
||||
| 8.24 | [Use of cryptography ](../../MoCs/ISO_27002_2022_8.24_MoC%20Use%20of%20cryptography.md) | 10.1.1, 10.1.2 |
|
||||
| 8.25 | [Secure development life cycle ](../../MoCs/ISO_27002_2022_8.25_MoC%20Secure%20development%20life%20cycle.md) | 14.2.1 |
|
||||
| 8.26 | [Application security requirements ](../../MoCs/ISO_27002_2022_8.26_MoC%20Application%20security%20requirements.md) | 14.1.2, 14.1.3 |
|
||||
| 8.27 | [Secure system architecture and engineering principles ](../../MoCs/ISO_27002_2022_8.27_MoC%20Secure%20system%20architecture%20and%20engineering%20principles.md) | 14.2.5 |
|
||||
| 8.28 | [Secure coding ](../../MoCs/ISO_27002_2022_8.28_MoC%20Secure%20coding.md) | New |
|
||||
| 8.29 | [Security testing in development and acceptance ](../../MoCs/ISO_27002_2022_8.29_MoC%20Security%20testing%20in%20development%20and%20acceptance.md) | 14.2.8, 14.2.9 |
|
||||
| 8.30 | [Outsourced development ](../../MoCs/ISO_27002_2022_8.30_MoC%20Outsourced%20development.md) | 14.2.7 |
|
||||
| 8.31 | [Separation of development, test and production environments ](../../MoCs/ISO_27002_2022_8.31_MoC%20Separation%20of%20development,%20test%20and%20production%20environments.md) | 12.1.4, 14.2.6 |
|
||||
| 8.32 | [Change management ](../../MoCs/ISO_27002_2022_8.32_MoC%20Change%20management.md) | 12.1.2, 14.2.2, 14.2.3, 14.2.4 |
|
||||
| 8.33 | [Test information ](../../MoCs/ISO_27002_2022_8.33_MoC%20Test%20information.md) | 14.3.1 |
|
||||
| 8.34 | [Protection of information systems during audit testing ](../../MoCs/ISO_27002_2022_8.34_MoC%20Protection%20of%20information%20systems%20during%20audit%20testing.md) | 12.7.1 |
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
#iso27002/2022/EN
|
||||
|
||||
| 2022 ID | Control title | Maatregel |
|
||||
| :------ | :--------------------------------------------------------------------- | :---------------------------------------------------------------------------- |
|
||||
| 5.1 | Policies for information security | Beleidsregels voor informatiebeveiliging |
|
||||
| 5.2 | Information security roles and responsibilities | Rollen en verantwoordelijkheden bij informatiebeveiliging |
|
||||
| 5.3 | Segregation of duties | Functiescheiding |
|
||||
| 5.4 | Management responsibilities | Managementverantwoordelijkheden |
|
||||
| 5.5 | Contact with authorities | Contact met overheidsinstanties |
|
||||
| 5.6 | Contact with special interest groups | Contact met speciale belangengroepen |
|
||||
| 5.7 | Threat intelligence | Informatie en analyses over dreigingen |
|
||||
| 5.8 | Information security in project management | Informatiebeveiliging in projectmanagement |
|
||||
| 5.9 | Inventory of information and other associated assets | Inventarisatie van informatie en andere gerelateerde bedrijfsmiddelen |
|
||||
| 5.10 | Acceptable use of information and other associated assets | Aanvaardbaar gebruik van informatie en andere gerelateerde bedrijfsmiddelen |
|
||||
| 5.11 | Return of assets | Retourneren van bedrijfsmiddelen |
|
||||
| 5.12 | Classification of information | Classificeren van informatie |
|
||||
| 5.13 | Labelling of information | Labelen van informatie |
|
||||
| 5.14 | Information transfer | Overdragen van informatie |
|
||||
| 5.15 | Access control | Toegangsbeveiliging |
|
||||
| 5.16 | Identity management | Identiteitsbeheer |
|
||||
| 5.17 | Authentication information | Beheren van authenticatie-informatie |
|
||||
| 5.18 | Access rights | Toegangsrechten |
|
||||
| 5.19 | Information security in supplier relationships | Informatiebeveiliging in leveranciersrelaties |
|
||||
| 5.20 | Addressing information security within supplier agreements | Adresseren van informatiebeveiliging in leveranciersovereenkomsten |
|
||||
| 5.21 | Managing information security in the ICT supply chain | Beheren van informatiebeveiliging in de ICT-keten |
|
||||
| 5.22 | Monitoring, review and change management of supplier services | Monitoren, beoordelen en het beheren van wijzigingen van leveranciersdiensten |
|
||||
| 5.23 | Information security for use of cloud services | Informatiebeveiliging voor het gebruik van clouddiensten |
|
||||
| 5.24 | Information security incident management planning and preparation | Plannen en voorbereiden van het beheer van informatiebeveiligingsincidenten |
|
||||
| 5.25 | Assessment and decision on information security events | Beoordelen van en besluiten over informatiebeveiligingsgebeurtenissen |
|
||||
| 5.26 | Response to information security incidents | Reageren op informatiebeveiligingsincidenten |
|
||||
| 5.27 | Learning from information security incidents | Leren van informatiebeveiligingsincidenten |
|
||||
| 5.28 | Collection of evidence | Verzamelen van bewijsmateriaal |
|
||||
| 5.29 | Information security during disruption | Informatiebeveiliging tijdens een verstoring |
|
||||
| 5.30 | ICT readiness for business continuity | ICT-gereedheid voor bedrijfscontinuïteit |
|
||||
| 5.31 | Legal, statutory, regulatory and contractual requirements | Wettelijke, statutaire, regelgevende en contractuele eisen |
|
||||
| 5.32 | Intellectual property rights | Intellectuele-eigendomsrechten |
|
||||
| 5.33 | Protection of records | Beschermen van registraties |
|
||||
| 5.34 | Privacy and protection of PII | Privacy en bescherming van persoonsgegevens |
|
||||
| 5.35 | Independent review of information security | Onafhankelijke beoordeling van informatiebeveiliging |
|
||||
| 5.36 | Compliance with policies, rules and standards for information security | Naleving van beleid, regels en normen voor informatiebeveiliging |
|
||||
| 5.37 | Documented operating procedures | Gedocumenteerde bedieningsprocedures |
|
||||
| 6.1 | Screening | Screening |
|
||||
| 6.2 | Terms and conditions of employment | Arbeidsovereenkomst |
|
||||
| 6.3 | Information security awareness, education and training | Bewustwording van, opleiding en training in informatiebeveiliging |
|
||||
| 6.4 | Disciplinary process | Disciplinaire procedure |
|
||||
| 6.5 | Responsibilities after termination or change of employment | Verantwoordelijkheden na beëindiging of wijziging van het dienstverband |
|
||||
| 6.6 | Confidentiality or non-disclosure agreements | Vertrouwelijkheids- of geheimhoudingsovereenkomsten |
|
||||
| 6.7 | Remote working | Werken op afstand |
|
||||
| 6.8 | Information security event reporting | Melden van informatiebeveiligingsgebeurtenissen |
|
||||
| 7.1 | Physical security perimeters | Fysieke beveiligingszones |
|
||||
| 7.2 | Physical entry | Fysieke toegangsbeveiliging |
|
||||
| 7.3 | Securing offices, rooms and facilities | Beveiligen van kantoren, ruimten en faciliteiten |
|
||||
| 7.4 | Physical security monitoring | Monitoren van de fysieke beveiliging |
|
||||
| 7.5 | Protecting against physical and environmental threats | Beschermen tegen fysieke en omgevingsdreigingen |
|
||||
| 7.6 | Working in secure areas | Werken in beveiligde zones |
|
||||
| 7.7 | Clear desk and clear screen | ‘Clear desk’ en ‘clear screen’ |
|
||||
| 7.8 | Equipment siting and protection | Plaatsen en beschermen van apparatuur |
|
||||
| 7.9 | Security of assets off-premises | Beveiligen van bedrijfsmiddelen buiten het terrein |
|
||||
| 7.10 | Storage media | Opslagmedia |
|
||||
| 7.11 | Supporting utilities | Nutsvoorzieningen |
|
||||
| 7.12 | Cabling security | Beveiligen van bekabeling |
|
||||
| 7.13 | Equipment maintenance | Onderhoud van apparatuur |
|
||||
| 7.14 | Secure disposal or re-use of equipment | Veilig verwijderen of hergebruiken van apparatuur |
|
||||
| 8.1 | User endpoint devices | ‘User endpoint devices’ |
|
||||
| 8.2 | Privileged access rights | Speciale toegangsrechten |
|
||||
| 8.3 | Information access restriction | Beperking toegang tot informatie |
|
||||
| 8.4 | Access to source code | Toegangsbeveiliging op broncode |
|
||||
| 8.5 | Secure authentication | Beveiligde authenticatie |
|
||||
| 8.6 | Capacity management | Capaciteitsbeheer |
|
||||
| 8.7 | Protection against malware | Bescherming tegen malware |
|
||||
| 8.8 | Management of technical vulnerabilities | Beheer van technische kwetsbaarheden |
|
||||
| 8.9 | Configuration management | Configuratiebeheer |
|
||||
| 8.10 | Information deletion | Wissen van informatie |
|
||||
| 8.11 | Data masking | Maskeren van gegevens |
|
||||
| 8.12 | Data leakage prevention | Voorkomen van gegevenslekken (Data leakage prevention) |
|
||||
| 8.13 | Information backup | Back-up van informatie |
|
||||
| 8.14 | Redundancy of information processing facilities | Redundantie van informatieverwerkende faciliteiten |
|
||||
| 8.15 | Logging | Logging |
|
||||
| 8.16 | Monitoring activities | Monitoren van activiteiten |
|
||||
| 8.17 | Clock synchronization | Kloksynchronisatie |
|
||||
| 8.18 | Use of privileged utility programs | Gebruik van speciale systeemhulpmiddelen |
|
||||
| 8.19 | Installation of software on operational systems | Installeren van software op operationele systemen |
|
||||
| 8.20 | Networks security | Beveiliging netwerkcomponenten |
|
||||
| 8.21 | Security of network services | Beveiliging van netwerkdiensten |
|
||||
| 8.22 | Segregation of networks | Netwerksegmentatie |
|
||||
| 8.23 | Web filtering | Toepassen van webfilters |
|
||||
| 8.24 | Use of cryptography | Gebruik van cryptografie |
|
||||
| 8.25 | Secure development life cycle | Beveiligen tijdens de ontwikkelcyclus |
|
||||
| 8.26 | Application security requirements | Toepassingsbeveiligingseisen |
|
||||
| 8.27 | Secure system architecture and engineering principles | Veilige systeemarchitectuur en technische uitgangspunten |
|
||||
| 8.28 | Secure coding | Veilig coderen |
|
||||
| 8.29 | Security testing in development and acceptance | Testen van de beveiliging tijdens ontwikkeling en acceptatie |
|
||||
| 8.30 | Outsourced development | Uitbestede systeemontwikkeling |
|
||||
| 8.31 | Separation of development, test and production environments | Scheiding van ontwikkel-, test- en productieomgevingen |
|
||||
| 8.32 | Change management | Wijzigingsbeheer |
|
||||
| 8.33 | Test information | Testgegevens |
|
||||
| 8.34 | Protection of information systems during audit testing | Bescherming van informatiesystemen tijdens audits |
|
||||
44
Corpus/Standards/ISO27x/about/ISO_27002_2022_What's_New.md
Normal file
44
Corpus/Standards/ISO27x/about/ISO_27002_2022_What's_New.md
Normal file
|
|
@ -0,0 +1,44 @@
|
|||
#iso27002/2022/EN
|
||||
Source:[ Wentz Wu](https://wentzwu.com/2022/02/16/iso-iec-270022022-controls/)
|
||||
Publishing date February 16, 2022
|
||||
Retrieved February 17, 2022
|
||||
|
||||
ISO 27001:2013 had 114 controls in Annex A, ISO/IEC 27002:2022 introduces 93 controls.
|
||||
|
||||
https://ictinstitute.nl/iso270022022-what-is-new/
|
||||
See also [[ICT Institute's ISO 27002 2022 in plain English]]
|
||||
|
||||
Wentz Wu has created a 'control taxonomy' in [](ISO-27002-2022-Controls-categorized.pdf):
|
||||
|
||||
- Control type: Preventive, Detective, and Corrective.
|
||||
- Information security properties: Confidentiality, Integrity and Availability.
|
||||
- Cybersecurity concepts: Identify, Protect, Detect, Respond and Recover.
|
||||
- Security domains: Governance_and_Ecosystem, Protection, Defence and Resilience
|
||||
- Operational capabilities: see below.
|
||||
|
||||
Operational capabilities:
|
||||
1. Governance
|
||||
2. Asset_management
|
||||
3. Information_protection
|
||||
4. Human_resource_security
|
||||
5. Physical_security
|
||||
6. System_and_network_security
|
||||
7. Application_security
|
||||
8. Secure_configuration
|
||||
9. Identity_and_access_management
|
||||
10. Threat_and_vulnerability_management
|
||||
11. Continuity
|
||||
12. Supplier_relationships_security
|
||||
13. Legal_and_compliance
|
||||
14. Information_security_event_management
|
||||
15. **Information_security_assurance**
|
||||
|
||||
The norm categorizes the controls in 4 sections:
|
||||
- people controls (i.e. individuals)
|
||||
- physical controls
|
||||
- technological controls
|
||||
- organizational controls
|
||||
|
||||
|
||||
|
||||
|
||||
BIN
Corpus/Standards/ISO27x/about/ISO_27005_2022_EN.pdf
Normal file
BIN
Corpus/Standards/ISO27x/about/ISO_27005_2022_EN.pdf
Normal file
Binary file not shown.
BIN
Corpus/Standards/ISO27x/about/ISO_IEC-27002_2022-Controls_I.jpg
Normal file
BIN
Corpus/Standards/ISO27x/about/ISO_IEC-27002_2022-Controls_I.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 307 KiB |
BIN
Corpus/Standards/ISO27x/about/ISO_IEC-27002_2022-Controls_II.jpg
Normal file
BIN
Corpus/Standards/ISO27x/about/ISO_IEC-27002_2022-Controls_II.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 309 KiB |
Binary file not shown.
BIN
Corpus/Standards/ISO27x/about/ISO_IEC_27701_2019_EN.pdf
Normal file
BIN
Corpus/Standards/ISO27x/about/ISO_IEC_27701_2019_EN.pdf
Normal file
Binary file not shown.
|
|
@ -0,0 +1,19 @@
|
|||
# MoC Roles and responsibilities in ISO 27001
|
||||
|
||||
**See**:
|
||||
|
||||
Recent:
|
||||
- [Explicitly mentioned roles in ISO 27001](Explicitly%20mentioned%20roles%20in%20ISO%2027001.md)
|
||||
- [ISO 27001 Leadership Responsibilities](ISO%2027001%20Leadership%20Responsibilities.md)
|
||||
- [ISO 27001 Top Management responsibilities](ISO%2027001%20Top%20Management%20responsibilities.md)
|
||||
- [Governance model for Policies and Controls](Governance%20model%20for%20Policies%20and%20Controls.md)
|
||||
- [Basic ISMS governance model](../../../ISMS/Basic%20ISMS%20governance%20model.md)
|
||||
- [m400-more-governance](../../../../../iso27DIY-gis/guide/m400/m400-more-governance.md)
|
||||
|
||||
Older:
|
||||
- [Roles and Responsibilities](../../../ISMS/Roles%20and%20Responsibilities.md)
|
||||
- [Risk ownership](../../../Information%20Security/Risks/Risk%20ownership.md)
|
||||
- [Ideas on Risk Ownership](../../../ISMS/Ideas%20on%20Risk%20Ownership.md)
|
||||
- [Asset ownership](../../Sparks/Asset%20ownership.md)
|
||||
- [Procuratieregeling](../../../Various/Procuratieregeling.md)
|
||||
- [Control ownership](../../../ISMS/Control%20ownership.md)
|
||||
BIN
Corpus/Standards/ISO27x/about/NEN-EN-ISO_IEC 27018_2020 en.pdf
Normal file
BIN
Corpus/Standards/ISO27x/about/NEN-EN-ISO_IEC 27018_2020 en.pdf
Normal file
Binary file not shown.
BIN
Corpus/Standards/ISO27x/about/NEN-ISO-IEC 27017-2015 en.pdf
Normal file
BIN
Corpus/Standards/ISO27x/about/NEN-ISO-IEC 27017-2015 en.pdf
Normal file
Binary file not shown.
BIN
Corpus/Standards/ISO27x/about/NEN-ISO-IEC 27034-5-2017 en.pdf
Normal file
BIN
Corpus/Standards/ISO27x/about/NEN-ISO-IEC 27034-5-2017 en.pdf
Normal file
Binary file not shown.
BIN
Corpus/Standards/ISO27x/about/NIS_2_and_ISO_27001_2022.pdf
Normal file
BIN
Corpus/Standards/ISO27x/about/NIS_2_and_ISO_27001_2022.pdf
Normal file
Binary file not shown.
|
|
@ -0,0 +1,35 @@
|
|||
# Nieuwe beheersmaatregelen in ISO 27001:2022
|
||||
|
||||
Gebaseerd op [Aanpassingen in ISO 27001:2023](../OST/ISO_27001_2023_NL_Aanpassingen.md#Nieuwe%20beheersmaatregelen%20in%20Annex%20A)
|
||||
Verwerkt in [Informatiebeveiligingsbeleid ISO 27001](../Implementation%20Products/Informatiebeveiligingsbeleid%20ISO%2027001.md)
|
||||
|
||||
| Maatregel | **Paragraaf** |
|
||||
| :------------------------------------------------------------ | :--------------------------------------------------------------------------------- |
|
||||
| 5.7 Informatie en analyses over dreigingen | 3.2 Risicobeheer |
|
||||
| 5.23 Informatiebeveiliging voor het gebruik van clouddiensten | 3.10 Leveranciersrelaties (of 3.7 Operationele beveiliging, indien intern/private) |
|
||||
| 5.30 ICT-gereedheid voor bedrijfscontinuïteit | 3.12 Beheer van bedrijfscontinuïteit |
|
||||
| 7.4 Monitoren van de fysieke beveiliging | 3.6 Fysieke en omgevingsbeveiliging |
|
||||
| 8.9 Configuratiebeheer | 3.7 Operationele beveiliging |
|
||||
| 8.10 Wissen van informatie | 3.4 Activabeheer en -classificatie |
|
||||
| 8.11 Maskeren van gegevens | 3.4 Activabeheer en -classificatie |
|
||||
| 8.12 Voorkomen van gegevenslekken | 3.4 Activabeheer en -classificatie |
|
||||
| 8.16 Monitoren van activiteiten | 3.7 Operationele beveiliging |
|
||||
| 8.23 Toepassen van webfilters | 3.7 Operationele beveiliging |
|
||||
| 8.28 Veilig coderen | 3.9 Systeemaankoop, -ontwikkeling en -onderhoud |
|
||||
|
||||
|
||||
| **Paragraaf** | Maatregel |
|
||||
| :--------------------------------------------------------------------------------- | :------------------------------------------------------------ |
|
||||
| 3.2 Risicobeheer | 5.7 Informatie en analyses over dreigingen |
|
||||
| 3.4 Activabeheer en -classificatie | 8.10 Wissen van informatie |
|
||||
| 3.4 Activabeheer en -classificatie | 8.11 Maskeren van gegevens |
|
||||
| 3.4 Activabeheer en -classificatie | 8.12 Voorkomen van gegevenslekken |
|
||||
| 3.6 Fysieke en omgevingsbeveiliging | 7.4 Monitoren van de fysieke beveiliging |
|
||||
| 3.7 Operationele beveiliging | 8.9 Configuratiebeheer |
|
||||
| 3.7 Operationele beveiliging | 8.16 Monitoren van activiteiten |
|
||||
| 3.7 Operationele beveiliging | 8.23 Toepassen van webfilters |
|
||||
| 3.9 Systeemaankoop, -ontwikkeling en -onderhoud | 8.28 Veilig coderen |
|
||||
| 3.10 Leveranciersrelaties (of 3.7 Operationele beveiliging, indien intern/private) | 5.23 Informatiebeveiliging voor het gebruik van clouddiensten |
|
||||
| 3.12 Beheer van bedrijfscontinuïteit | 5.30 ICT-gereedheid voor bedrijfscontinuïteit |
|
||||
|
||||
|
||||
Binary file not shown.
|
|
@ -0,0 +1,15 @@
|
|||
# Physical security in ISO 27001
|
||||
|
||||
The article (or control) that deals explicitly with identifying secure areas, which are required to be protected, is **Control 7.1, "Physical security perimeters,"**.
|
||||
|
||||
This control is categorized under Clause 7, "Physical controls," of ISO/IEC 27002.
|
||||
|
||||
The purpose of Control 7.1 is **"To prevent unauthorized physical access, damage and interference to the organization’s information and other associated assets"**.
|
||||
|
||||
The guidance for this control explicitly states that:
|
||||
|
||||
- **Security perimeters should be defined and used to protect areas** that contain information and other associated assets.
|
||||
- The definition, siting, and strength of each perimeter should be **in accordance with the information security requirements related to the assets within the perimeter**.
|
||||
- A secure area can be considered a lockable office or several rooms surrounded by a continuous internal physical security barrier.
|
||||
|
||||
Following the definition of secure perimeters (7.1), **Control 7.2, "Physical entry,"** then addresses how these secure areas should be protected by appropriate entry controls and access points.
|
||||
9
Corpus/Standards/ISO27x/about/Privacy in ISO 27001.md
Normal file
9
Corpus/Standards/ISO27x/about/Privacy in ISO 27001.md
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
# Privacy in ISO 27001
|
||||
|
||||
[Core concepts of Privacy](Core%20concepts%20of%20Privacy.md)
|
||||
[AVG GDPR resources](../../AVG/AVG%20GDPR%20resources.md)
|
||||
|
||||
Privacy in ISO 27001:
|
||||
- [ISO 27001 A 18 Compliance](../legacy/ISO%2027001%202013/ISO%2027001%20A%2018%20Compliance.md#A%2018%201%204%20Privacy%20and%20protection%20of%20personally%20identifiable%20information)
|
||||
|
||||
[Personal Health Train | Health-RI](https://www.health-ri.nl/initiatives/personal-health-train)
|
||||
62
Corpus/Standards/ISO27x/about/Privacy in ISO 27k.md
Normal file
62
Corpus/Standards/ISO27x/about/Privacy in ISO 27k.md
Normal file
|
|
@ -0,0 +1,62 @@
|
|||
## Application specific guidelines
|
||||
[ISO/IEC 27017 cloud security](https://www.iso27001security.com/html/27017.html)
|
||||
> The code of practice provides additional information security controls implementation advice beyond that provided in ISO/IEC 27002, in the cloud computing context.
|
||||
> The standard advises both cloud service customers and cloud service providers, with the primary guidance laid out side-by-side in each section.
|
||||
|
||||
[ISO/IEC 27018 Code of practice for protection of Personally Identifiable Information (PII) in public clouds acting as PII processors](https://www.iso27001security.com/html/27018.html)
|
||||
> The standard is primarily concerned with public-cloud computing service providers acting as PII processors . “A public cloud service provider is a ‘PII processor’ when it processes PII for and according to the instructions of a cloud service customer”
|
||||
|
||||
[ISO/IEC 27030 Security and privacy for Internet of Things](https://www.iso27001security.com/html/27030.html)
|
||||
> The standard will provide guidance on the principles, risk and controls for IoT security and privacy. Currently at 2nd Committee Draft stage. The standard is due to be published in 2022.
|
||||
|
||||
[ISO/IEC 27046 Big data security and privacy implementation](https://www.iso27001security.com/html/27046.html)
|
||||
> This standard is intended to help organizations implement the processes described in [ISO/IEC 27045](https://www.iso27001security.com/html/27045.html) in order to ensure the security and privacy of big data. It is currently at Working Draft stage. The standard was due to be published in 2023. However, a hiatus on the [ISO/IEC 27045 ](https://www.iso27001security.com/html/27045.html) project implies this standard and its schedule is in doubt.
|
||||
|
||||
[ISO/IEC 27400 IoT security and privacy](https://www.iso27001security.com/html/27400.html)
|
||||
> The standard will provide guidance on the principles, risk and controls for IoT security and privacy. It identifies some generic ‘risk sources’ and ‘risk scenarios’ relevant to IoT, essentially a selection of examples for consideration. Currently at 3rd Committee Draft stage. The standard is due to be published in 2022.
|
||||
|
||||
## Management frameworks (?)
|
||||
[ISO/IEC 27701 Privacy information management](https://www.iso27001security.com/html/27701.html)
|
||||
> The standard specifies a Privacy Information Management System based on ISO/IEC 27001(ISMS), 27002 (security controls) and 29100 (privacy framework). It is applicable to both controllers and processors of Personally Identifiable Information.
|
||||
|
||||
[ISO/IEC TR 27550 Privacy engineering](https://www.iso27001security.com/html/27550.html)
|
||||
> This is an IT security standard about *engineering* IT systems to satisfy privacy requirements relating to the protection of personal data.
|
||||
|
||||
[ISO/IEC 27552 Extension to 27001/27002 for privacy information management](https://www.iso27001security.com/html/27552.html)
|
||||
> This standard will explain how to ‘enhance’ (adapt and extend) an ISO 27001 ISMS and the associated 27002 controls to manage privacy as well as information security. Currently at DIS stage. Due to be published at the end of 2019.
|
||||
|
||||
[ISO/IEC 27556 User-centric framework for the handling of PII and privacy preferences](https://www.iso27001security.com/html/27556.html)
|
||||
> The standard will lay out a “user-centric framework” (an architecture) to handle personal information in a controlled manner. […] It is at 2nd Committee Draft stage and is expected to be published in early in 2023.
|
||||
|
||||
[ISO/IEC 27557 Organizational privacy risk management](https://www.iso27001security.com/html/27557.html)
|
||||
> Currently at Working Draft stage. This standard will guide organizations on managing privacy risks that could impact the organization and/or data subjects.
|
||||
|
||||
[ISO/IEC 29100:2011 Privacy Framework](https://www.itgovernance.asia/shop/product/iso29100-iso-29100-privacy-framework)
|
||||
> ISO/IEC 29100:2011 provides a privacy framework for when dealing with PII. The standard:
|
||||
> Specifies a common privacy terminology
|
||||
> Defines the actors and their roles in processing PII
|
||||
> Describes privacy safeguarding considerations; and
|
||||
> Provides references to known privacy principles for information technology
|
||||
|
||||
|
||||
|
||||
27018 is vooral voor de rol van Verwerker.
|
||||
Bij 27018 ligt de focus op de garantie kunnen bieden aan de klant, dat er met zijn gegevens wordt omgegaan conform geldende privacy principes.
|
||||
Er wordt geen aandacht besteed aan de werking van de interne organisatie (tenzij dat nodig is voor het voorgaande).
|
||||
Het biedt maatregelen en richtlijnen in aanvulling op het 27001 ISMS en Annex A.
|
||||
Zo kun je 27018-compliant zijn in de dienstverlening aan de klant en de omgang met zijn gegevens (in de rol van verwerker), terwijl je intern (bijv. Bij HR en Marketing) niet voldoet aan de GDPR (in de rol van verwerkingsverantwoordelijke).
|
||||
Voorbeeld: A 4 Collection limitation: geen aanvullende maatregelen, terwijl dit in bijv een Client Onboarding proces van belang is.
|
||||
A 5 Data minimisation: alleen veilige verwijdering van tijdelijke bestanden. Terwijl de typische marketing afdeling zelden contactgegevens verwijdert als ze ze eenmaal in handen hebben.
|
||||
27018:A.10.1 Notification of a data breach involving PII gaat primair over de verplichtingen richting de klant m.b.t. het lekken van hun data.
|
||||
|
||||
* BCR/SCC worden niet genoemd in de 27018
|
||||
|
||||
|
||||
27701 focust op de rol als Verwerkingsverantwoordelijke.
|
||||
|
||||
|
||||
The Information Security Management System (ISMS) defined in ISO/IEC 27001 is designed to permit the addition of sector specific requirements, without the need to develop a new Management System. ISO Management System standards, including the sector specific ones, are designed to be able to be implemented either separately or as a combined Management System.
|
||||
|
||||
maintaining and continually improving a Privacy Information Management System (PIMS) in the form of an extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy management within the context of the organization.
|
||||
|
||||
This document specifies PIMS-relate
|
||||
97
Corpus/Standards/ISO27x/about/Risk Treatment Plan.md
Normal file
97
Corpus/Standards/ISO27x/about/Risk Treatment Plan.md
Normal file
|
|
@ -0,0 +1,97 @@
|
|||
# Risk Treatment Plan
|
||||
|
||||
Find faults or omissions in my reasoning.
|
||||
|
||||
The Canonical Form of a policy is:
|
||||
>To mitigate the risk of R, control C will be implemented on asset A under the responsibility of asset owner AO. The effectiveness will be measured through method M and will be evaluated by risk owner RO, against established risk criteria RC.
|
||||
|
||||
**A Corrected Canonical Form (for a Risk Treatment Plan):**
|
||||
> "To treat risk R (evaluated against Risk Criteria RC), Control C will be implemented by assigned Actor [Control Implementer], to protect Asset A (owned by Asset Owner AO). The effectiveness of Control C will be measured by Actor [Evaluator] using Method M against established Objectives/Performance Criteria, producing Artifact [Evidence]. Finally, Risk Owner RO will review the evidence to approve the treatment plan and accept the residual risk."
|
||||
|
||||
### Faults in your reasoning
|
||||
|
||||
**1. Misclassification as a "Policy"** Your canonical form reads as a highly specific operational directive, which belongs in a **Risk Treatment Plan** or a **Statement of Applicability (SoA)**, not a policy.
|
||||
|
||||
- **Policies** formally express the high-level intentions and direction of top management (e.g., "We will manage access to our servers"). They are general or high-level.
|
||||
- **Procedures** detail the _how_.
|
||||
- The **Risk Treatment Plan** is the formal document where the organization specifies how it will treat identified risks by linking them to necessary controls, while the **SoA** justifies their inclusion.
|
||||
|
||||
**2. "Mitigate" vs. "Modify or Maintain"** You state the control is implemented "to _mitigate_ the risk". While mitigation is a common treatment option, ISO 27002 explicitly defines a **control** as a measure that **modifies or maintains risk**. Some controls (like an overarching policy) only _maintain_ risk at a known level, while compliance with that policy _modifies_ it. Mitigation is just one outcome; controls can also support risk avoidance or risk sharing.
|
||||
|
||||
**3. Responsibility: Asset Owner vs. Control Owner/Implementer** You assert the control is implemented "under the responsibility of asset owner AO". This conflates asset ownership with control implementation.
|
||||
|
||||
- The **Asset Owner** is responsible for the proper management of the asset over its whole life cycle, ensuring it is classified and that access restrictions correspond with that classification.
|
||||
- However, the responsibility for implementing specific **controls** (e.g., running backups, configuring firewalls) is allocated to various roles according to organizational needs. As illustrated in the TypeDB schema, an `actor` (like a specific IT manager or department) can play the `responsible-for` role for a control, independently of who owns the asset.
|
||||
|
||||
**4. The Role of the Risk Owner in Evaluation** You state the effectiveness will be evaluated by the **Risk Owner (RO)**. This is a subtle fault in the division of duties.
|
||||
|
||||
- Under ISO 27001, the organization must determine _who_ shall monitor and measure, and _who_ shall evaluate the results. This is often a security officer, an auditor, or an independent reviewer (as per control 5.35).
|
||||
- The explicit responsibility of the **Risk Owner** in the standard is to **approve the information security risk treatment plan and accept the residual information security risks**. They consume the evaluation data to make acceptance decisions, but they do not necessarily execute the evaluation of the measurement method.
|
||||
|
||||
**5. Evaluating Effectiveness against "Risk Criteria"** You state effectiveness is evaluated against "established risk criteria RC". This mixes two different clauses of the standard.
|
||||
|
||||
- **Risk criteria** (which include risk acceptance criteria) are established to evaluate and prioritize _risks_ during the risk assessment phase.
|
||||
- The **effectiveness of controls** and the ISMS itself is evaluated through monitoring and measurement methods to ensure the controls achieve their **information security objectives** and intended outcomes.
|
||||
-
|
||||
### Omissions in your reasoning
|
||||
|
||||
**1. Artifacts and Evidence** To prove that a control has been implemented and measured effectively, the standard requires documented information as evidence. According to the TypeDB schema, an **artifact** (like a record or log) must be captured and linked via a `serves-as-evidence-for` relationship to the control or process. Your form omits the requirement to generate and maintain evidence.
|
||||
|
||||
**2. Traceability to Clauses and Requirements** Your form connects a control directly to a risk, which is correct. However, ISO 27001 and the TypeDB schema also mandate that controls address specific **Requirements** defined within the standard's **Clauses**. An organization implements controls not _just_ to treat a risk, but also to satisfy mandatory compliance, legal, or standard requirements (e.g., ISO 27001 Annex A).
|
||||
|
||||
### A Corrected Canonical Form (for a Risk Treatment Plan)
|
||||
|
||||
If adapted to accurately reflect the framework's data model and terminology, the canonical form for a **Risk Treatment entry** would be:
|
||||
|
||||
**"To treat risk R (evaluated against Risk Criteria RC), Control C will be implemented by assigned Actor [Control Implementer], to protect Asset A (owned by Asset Owner AO), fulfilling Requirement Req. The effectiveness of Control C will be measured by Actor [Evaluator] using Method M against established Objectives/Performance Criteria, producing Artifact [Evidence]. Finally, Risk Owner RO will review the evidence to approve the treatment plan and accept the residual risk."**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Elements
|
||||
|
||||
To establish the compliance of the implementation of a specific control to the ISO 27001 standard, the auditor will look for the following:
|
||||
- the risk that the control is supposed to mitigate
|
||||
- the risk owner
|
||||
- the scope of the control, in terms of organizational scope (certain business activities, organizational units) and asset(s) protected
|
||||
- the control owner
|
||||
- a description of the 'how' or the activities involved in the implementation, including roles and responsibilities
|
||||
- how the effectiveness of the control will be established, when, and by whom
|
||||
- how the effectiveness of the control will be evaluated, when, and by whom
|
||||
- possible exemptions to the policy
|
||||
- how exceptions will be handled
|
||||
- where all this is documented (policies, logs etc., evaluation)
|
||||
- for this documentation: Version information and who has authoured and signed off on the policy, Revision dates (+ next evaluation)
|
||||
- what the change procedure is for a relevant policy
|
||||
|
||||
|
||||
|
||||
**"Formally":**
|
||||
- A policy formally expresses the intentions and direction of management. Rather than detailing exactly _how_ a task should be executed, the overarching information security policy is supported by "topic-specific policies" **as needed** to mandate the implementation of controls for specific target groups or security areas (such as access control, physical security, or secure development).
|
||||
- **The Role of a Procedure (The "How"):** The specific steps on _how_ to carry out an activity or process are defined in a **procedure**. For example, Control 5.37 requires organizations to maintain "documented operating procedures" that provide personnel with the detailed, step-by-step instructions needed to ensure the correct and secure operation of information processing facilities
|
||||
- It is also important to note that a control is broadly defined as **any measure that modifies or maintains risk**. Therefore, a control itself can take the form of a policy, a procedure, a process, or a technical hardware/software function
|
||||
|
||||
|
||||
Version Control
|
||||
|
||||
| Type | Value |
|
||||
| --------------- | ----- |
|
||||
| Version number: | x.xx |
|
||||
| Version date: | x.xx |
|
||||
| Document owner: | name |
|
||||
| Approved by: | name |
|
||||
| Approved on: | date |
|
||||
| Next review: | date |
|
||||
|
||||
The Document Owner is responsible for development and implementation of the policy.
|
||||
|
||||
- [ ] Check Standard on documentation and ownership
|
||||
|
||||
|
||||
## Approved
|
||||
Name: | name
|
||||
--- | ---
|
||||
Signature: | signature
|
||||
Date: | date
|
||||
51
Corpus/Standards/ISO27x/about/Risk Treatment in ISO 27001.md
Normal file
51
Corpus/Standards/ISO27x/about/Risk Treatment in ISO 27001.md
Normal file
|
|
@ -0,0 +1,51 @@
|
|||
# Risk Treatment in ISO 27001
|
||||
|
||||
Based on the ISO 27000 series (specifically ISO 27000 for definitions/overview and ISO 27001 for requirements), the standards outline four primary options for treating information security risks.
|
||||
|
||||
### 1. Options for Risk Treatment
|
||||
According to ISO 27000, which provides the overview and vocabulary for the ISO 27001 standard, a risk treatment decision involves selecting one of the following options[^1][^2]:
|
||||
|
||||
* **Risk Reduction (Applying Controls):** This involves modifying the risk by applying appropriate information security controls to reduce the likelihood or consequences of an incident[^1][^2].
|
||||
* **Risk Retention (Acceptance):** This option involves knowingly and objectively accepting the risk, provided it satisfies the organization's policy and criteria for risk acceptance[^2][^3]. This is an informed decision to take a particular risk, which may occur without treatment or after treatment controls have been applied (residual risk)[^4].
|
||||
* **Risk Avoidance:** This involves deciding not to start or continue with the activity that gives rise to the risk, thereby avoiding the risk entirely.
|
||||
* **Risk Sharing:** This involves sharing the associated risk with other parties, such as through insurance contracts or by working with suppliers.
|
||||
|
||||
### 2. The Risk Treatment Process in ISO 27001
|
||||
ISO 27001 specifies the requirements for applying these options within an Information Security Management System (ISMS). When planning risk treatment, an organization must define and apply a process that includes the following steps:
|
||||
|
||||
* **Select Options:** Select appropriate risk treatment options based on the results of the risk assessment[^5].
|
||||
* **Determine Controls:** Determine the necessary controls to implement the chosen treatment options. Organizations can design these controls themselves or identify them from any source[^6].
|
||||
* **Compare with Annex A:** Compare the determined controls against the list of possible information security controls found in **Annex A** of ISO 27001 to ensure no necessary controls have been overlooked.
|
||||
* **Produce a Statement of Applicability (SoA):** This document must list the necessary controls, justify their inclusion, state whether they are implemented, and justify the exclusion of any Annex A controls[^7].
|
||||
* **Formulate a Plan:** Create an information security risk treatment plan[^8].
|
||||
* **Obtain Approval:** The risk owners must approve the risk treatment plan and accept the residual information security risks (the risk remaining after treatment).
|
||||
|
||||
### 3. Implementing Controls (Risk Reduction)
|
||||
If the decision is to reduce risk by applying controls, ISO 27001 and ISO 27002 provide a comprehensive reference set. ISO 27001 Annex A lists controls derived from ISO 27002, organized into four themes:
|
||||
* **Organizational controls** (e.g., policies, return of assets).
|
||||
* **People controls** (e.g., screening, remote working).
|
||||
* **Physical controls** (e.g., physical security perimeters, clear desk policy).
|
||||
* **Technological controls** (e.g., protection against malware, data leakage prevention).
|
||||
|
||||
### Analogy
|
||||
To visualize these options, imagine you are managing the risk of a car accident:
|
||||
* **Reduction:** You drive a car with advanced brakes and airbags (applying controls).
|
||||
* **Avoidance:** You decide to walk instead of drive (eliminating the activity causing the risk).
|
||||
* **Sharing:** You purchase auto insurance so the financial burden is shared with the insurer.
|
||||
* **Retention:** You understand that despite your safe driving and insurance, a minor scratch might still happen, and you are willing to accept that possibility.
|
||||
|
||||
[^1]: ISO/IEC 27000:2018 3.72 risk treatment process (3.54) to modify risk (3.61), Note 1 to entry
|
||||
|
||||
[^2]: ISO/IEC 27000:2018 4.5.4 Treating information security risks
|
||||
|
||||
[^3]: ISO/IEC 27000:2018 3.57 residual risk risk (3.61) remaining after risk treatment (3.72)
|
||||
|
||||
[^4]: ISO/IEC 27000:2018 3.62 risk acceptance informed decision to take a particular risk (3.61) Note 1 to entry: Risk acceptance can occur without risk treatment (3.72) or during the process (3.54) of risk treatment.
|
||||
|
||||
[^5]: ISO/IEC 27001:2022(E) 6.1.2 Information security risk assessment
|
||||
|
||||
[^6]: ISO/IEC 27001:2022(E) 6.1.3 Information security risk treatment
|
||||
|
||||
[^7]: ISO/IEC 27001:2022(E) 6.1.3 Information security risk treatment Note 3
|
||||
|
||||
[^8]: ISO/IEC 27001:2022(E) 6.1.3 Information security risk treatment e) and f)
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
# Risk assessment and treatment at two levels in ISO 27001
|
||||
|
||||
Risk assessment and risk treatment are discussed both in Chapter 6 and in Chapter 8. What is the difference?
|
||||
|
||||
|
||||
|
||||
The relationship between , (Information security risk assessment), and (Information security risk treatment) hinges on their roles within the Information Security Management System (ISMS) framework defined by ISO/IEC 27001:2022.
|
||||
|
||||
In essence, Clauses [6.1.2](../../../ISMS/Qualifying%20vs%20quantifying%20risks.md) and [6.1.3](../../MoCs/ISO_27001_2022_6.1.3_MoC%20Information%20security%20risk%20treatment.md) (Information security risk assessment and risk treatment) define the _processes_ and _criteria_ for risk management within the planning stage, while Clauses [8.2](../../MoCs/ISO_27001_2022_8.2_MoC%20Information%20security%20risk%20assessment.md) and [8.3](../../MoCs/ISO_27001_2022_8.3_MoC%20Information%20security%20risk%20treatment.md) define the _operational execution_ and _timing_ for applying those established processes.
|
||||
|
||||
### 1. Risk Processes Defined (Planning: Clause 6)
|
||||
|
||||
Clauses 6.1.2 and 6.1.3, located within the **Planning (Clause 6)** section of the ISO/IEC 27001 requirements, establish the foundational framework and repeatable methodology for how the organization approaches risk management:
|
||||
|
||||
- **6.1.2 Information security risk assessment:** This clause mandates the **definition and application** of a risk assessment process. This process includes:
|
||||
|
||||
- Establishing and maintaining risk criteria, including risk acceptance criteria.
|
||||
- Ensuring that repeated assessments produce consistent, valid, and comparable results.
|
||||
- Identifying, analyzing, and evaluating information security risks associated with the loss of confidentiality, integrity, and availability within the scope of the ISMS, and determining risk owners.
|
||||
- The organization must **retain documented information** about this defined risk assessment process.
|
||||
- **6.1.3 Information security risk treatment:** This clause mandates the **definition and application** of a risk treatment process. This process involves:
|
||||
|
||||
- Selecting appropriate risk treatment options based on assessment results.
|
||||
- Determining all necessary controls needed to implement the chosen treatment options.
|
||||
- **Comparing** the determined controls against those listed in **Annex A** (which is directly derived from ISO/IEC 27002 controls) to ensure no necessary controls have been omitted.
|
||||
- Producing a **Statement of Applicability (SoA)** detailing the controls chosen, justification for inclusion, implementation status, and justification for excluding any Annex A controls.
|
||||
- Formulating an **Information security risk treatment plan**.
|
||||
- Obtaining approval for the treatment plan and acceptance of residual risks from risk owners.
|
||||
- The organization must **retain documented information** about this defined risk treatment process.
|
||||
- The risk assessment and treatment processes align with the principles and guidelines found in ISO 31000.
|
||||
|
||||
### 2. Risk Processes Implemented (Operation: Clause 8)
|
||||
|
||||
Clauses 8.2 and 8.3, located within the **Operation (Clause 8)** section, describe when and how the processes defined in Clause 6.1.2 and 6.1.3 must be actively performed by the organization.
|
||||
|
||||
- **8.2 Information security risk assessment:** This clause specifies the **trigger events** for conducting the risk assessment defined earlier in 6.1.2. The organization must perform risk assessments at **planned intervals** or when **significant changes are proposed or occur**. These assessments must follow the criteria established in 6.1.2 a).
|
||||
|
||||
- The organization is required to retain documented information of the **results** of these operational risk assessments.
|
||||
- **8.3 Information security risk treatment:** This clause specifies the **action** required following the determination of the risk treatment plan (formulated in 6.1.3 e)). The organization must **implement the information security risk treatment plan**.
|
||||
|
||||
- The organization is required to retain documented information of the **results** of this operational risk treatment.
|
||||
|
||||
### Summary of the Relationship
|
||||
|
||||
|Clause|Section|Focus|Purpose in the ISMS Cycle|
|
||||
|:--|:--|:--|:--|
|
||||
|**6.1.2** (Risk assessment)|Planning|**Defining the Risk Methodology**|Establishes _how_ risk assessment will be performed (criteria, repeatable process, identification, analysis, evaluation).|
|
||||
|**6.1.3** (Risk treatment)|Planning|**Defining the Treatment Framework**|Establishes _how_ risks will be treated (control selection, comparison with Annex A, SoA creation, plan formulation, residual risk acceptance).|
|
||||
|**8.2** (Risk assessment)|Operation|**Executing the Assessment**|Defines _when_ the defined risk assessment process (6.1.2) must be carried out (planned intervals or significant changes).|
|
||||
|**8.3** (Risk treatment)|Operation|**Executing the Treatment**|Requires the organization to _implement_ the risk treatment plan formulated during the planning stage (6.1.3).|
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
## Control 8.25: The development proces
|
||||
|
||||
Control 8.25, "Secure development life cycle," is the most overarching, establishing rules for integrating information security across the entire software and system development process [Source 1, 88]. Its focal point is on defining security within methodologies, setting checkpoints, and managing source code and configurations throughout the development lifecycle [Source 1, 88]. This control would be applied from the very beginning of the development process, laying the groundwork for how security is handled across all phases, including planning, design, implementation, and testing.
|
||||
## Controls 8.26 – 8.28: Specification, Design and Coding
|
||||
|
||||
Control 8.27, "Secure system architecture and engineering principles," centers on the foundational design and engineering principles for building secure systems [Source 1, 89]. Its purpose is to ensure that security is embedded from the ground up, incorporating concepts like "security by design" and "defence in depth" across all architectural layers [Source 1, 89]. This control is primarily applied during the **early architectural and design phases** of a software system.
|
||||
|
||||
Control 8.26, "Application security requirements," concentrates on identifying, specifying, and approving all necessary information security requirements for applications during their development or acquisition [Source 1, 88]. This involves a high-level definition of security objectives and constraints, often derived from risk assessments, business needs, legal, statutory, regulatory, and contractual requirements [Source 1, 88, 112]. It covers aspects like access control, data protection, and resilience against attacks [Source 1, 88]. This control is crucial during the **requirements and design phases**, defining *what* security an application needs to achieve.
|
||||
|
||||
Finally, Control 8.28, "Secure coding," specifically addresses the **practical application of secure programming techniques during the actual writing of software code** to minimize vulnerabilities [Source 1, 89]. Its focal point is on the technical methods and practices employed by developers, including adhering to secure coding principles, using secure development tools, and employing techniques like peer review and static analysis to ensure the software is built securely [Source 1, 89]. This control is directly implemented during the **coding and development** phases, focusing on *how* to technically implement the security defined by controls like 8.26.
|
||||
|
||||
In essence, controls 8.26 and 8.27 provide the "**what**" and "**why**" of security (requirements and foundational principles) during earlier phases, while 8.28 focuses on the "**how**" (technical implementation in code) during later, hands-on development phases.
|
||||
## Controls 8.29, 8.31, and 8.33: Testing
|
||||
|
||||
**Control 8.29, "Security testing in development and acceptance,"** focuses on **validating that information security requirements are met** when applications or code are deployed to the production environment . Its primary purpose is to ensure that new information systems, upgrades, and new versions are **thoroughly tested and verified for security during the development processes** . This control is a crucial part of the development lifecycle, specifically applied during the **testing and acceptance phases** before deployment to a live environment.
|
||||
|
||||
• **Control 8.31, "Separation of development, test and production environments,"** is foundational, establishing rules for **maintaining distinct and secure environments** for different stages of the system lifecycle [1, 2]. Its focal point is to prevent the compromise of live production data and systems by activities occurring in development or testing [2-4]. This control mandates measures like physical or virtual separation, strict authorization for software deployment, and prohibiting development tools from production systems [5, 6]. It is applied throughout the **setup and ongoing management of system environments**, ensuring that the integrity and confidentiality of production remain uncompromised during development and testing efforts [2, 5].
|
||||
|
||||
• **Control 8.33, "Test information,"** specifically addresses the **selection, protection, and management of data used in testing** [1, 10]. Its primary purpose is to **ensure the relevance and integrity of testing while rigorously protecting sensitive operational information** from exposure or misuse [10]. This control emphasizes strict measures, such as avoiding the direct copying of sensitive production data into development and testing environments, or requiring masking techniques if such data must be used [11]. It also mandates that test environments employ access controls comparable to production, that copying of operational information is authorized and logged, and that test data is securely deleted after use [12]. This control is directly applied during the **testing phase** of software and system development [11].
|
||||
|
||||
## Controls 8.32: Change management
|
||||
• **Control 8.32, "Change management,"** centers on the structured **control of all modifications to information processing facilities and information systems** [1, 7]. Its purpose is to **preserve information security** when changes are introduced, preventing unintended impacts on the confidentiality, integrity, and availability of information [7, 8]. This involves defining a formal process that includes planning, impact assessment, authorization, comprehensive testing, communication to relevant parties, and maintaining detailed records of all changes [9]. This control is crucial across the **entire system development lifecycle, including operational and maintenance phases**, ensuring that security is upheld with every alteration [8].
|
||||
|
||||
|
||||
In essence, while controls like 8.25 through 8.28 define _how secure software is built_, controls 8.31 through 8.33 provide the framework for _securely managing and deploying_ that software, focusing on the environments, processes, and data that surround the application as it moves from development to operation.
|
||||
8
Corpus/Standards/ISO27x/about/Tokens.md
Normal file
8
Corpus/Standards/ISO27x/about/Tokens.md
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
# Managing 2FA tokens
|
||||
|
||||
Does managing 2FA tokens fall under control: cryptographic key mgt? Probably.
|
||||
|
||||
Tokens are mentioned in:
|
||||
- 5.11 Return of assets (for hardware tokens)
|
||||
- 5.17 Authentication information
|
||||
- 8.5 Secure authentication
|
||||
27
Corpus/Standards/ISO27x/about/Types of Controls.md
Normal file
27
Corpus/Standards/ISO27x/about/Types of Controls.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# Types of Controls
|
||||
|
||||
From a [LinkedIn post](https://www.linkedin.com/posts/mohammad-salman-khan-a160a15_governance-riskmanagement-internalcontrols-activity-7344245989253206016-cYa3/).
|
||||
|
||||
**Preventive Controls** stop undesirable events or risks before they occur.
|
||||
Examples: Passwords, firewalls, access restrictions, segregation of duties.
|
||||
Comparable to a front door lock.
|
||||
|
||||
**Detective Controls** identify and flag events or deviations after they occur.
|
||||
Examples: Exception reports, surveillance, reconciliations, audit trails.
|
||||
Comparable to an intruder alarm system.
|
||||
|
||||
**Corrective Controls** limit the damage after an event and restore normal operations.
|
||||
Examples: Backup restoration, incident response plans, disciplinary actions.
|
||||
These are your recovery mechanisms—essential for resilience and continuity.
|
||||
|
||||
**Prescriptive Controls** define specific steps or rules to mitigate risks.
|
||||
Examples: SOPs, policy manuals, codes of conduct.
|
||||
They ensure consistency and compliance.
|
||||
|
||||
**Directive Controls** guide and influence behavior toward desired outcomes.
|
||||
Examples: Training, awareness programs, tone from the top, mission statements.
|
||||
These controls foster a strong risk culture by shaping mindset and behavior.
|
||||
|
||||
**Compensating Controls** serve as alternatives when primary controls are weak or absent.
|
||||
Examples: Manual review in place of automation, monitoring in place of Segregation of Duties.
|
||||
|
||||
|
|
@ -0,0 +1,184 @@
|
|||
---
|
||||
title: "Typical ISO 27001 certification costs"
|
||||
source: "https://www.itgovernance.co.uk/iso27001-certification-costs"
|
||||
author:
|
||||
published:
|
||||
created: 2025-06-23
|
||||
description: "Audit fees vary but, having helped hundreds of organisations achieve ISO 27001 certification in the last 15 years, we suggest you budget the following sums."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
We value your privacy
|
||||
|
||||
Customize Consent Preferences
|
||||
|
||||
We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.
|
||||
|
||||
The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site....
|
||||
|
||||
For more information on how Google's third-party cookies operate and handle your data, see:[Google Privacy Policy](https://business.safety.google/privacy)
|
||||
|
||||
Always Active
|
||||
|
||||
Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.
|
||||
|
||||
- Cookie
|
||||
CMSPreferredCulture
|
||||
- Duration
|
||||
1 year
|
||||
- Description
|
||||
Stores the user's preferred language or region setting to display content appropriately.
|
||||
- Cookie
|
||||
CMSPreferredUICulture
|
||||
- Duration
|
||||
past
|
||||
- Description
|
||||
Stores the user interface culture. Required for displaying content in the selected language.
|
||||
- Cookie
|
||||
CMSCsrfCookie
|
||||
- Duration
|
||||
session
|
||||
- Description
|
||||
- Cookie
|
||||
ASP.NET\_SessionId
|
||||
- Duration
|
||||
session
|
||||
- Description
|
||||
Maintains session state for a visitor across page requests.
|
||||
- Cookie
|
||||
ARRAffinity
|
||||
- Duration
|
||||
session
|
||||
- Description
|
||||
Used by Azure to ensure a visitor's session is consistently served by the same server.
|
||||
- Cookie
|
||||
ARRAffinitySameSite
|
||||
- Duration
|
||||
session
|
||||
- Description
|
||||
Same as ARRAffinity, with added protection for cross- site requests.
|
||||
- Cookie
|
||||
.ASPXANONYMOUS
|
||||
- Duration
|
||||
2 months 8 days 11 hours
|
||||
- Description
|
||||
- Cookie
|
||||
adnsf.notices
|
||||
- Duration
|
||||
session
|
||||
- Description
|
||||
- Cookie
|
||||
cartReminderCookie
|
||||
- Duration
|
||||
1 hour
|
||||
- Description
|
||||
Stores a reminder that a user has items in their shopping cart.
|
||||
- Cookie
|
||||
cookieyes-consent
|
||||
- Duration
|
||||
1 year
|
||||
- Description
|
||||
- Cookie
|
||||
JSESSIONID
|
||||
- Duration
|
||||
session
|
||||
- Description
|
||||
- Cookie
|
||||
\_\_cf\_bm
|
||||
- Duration
|
||||
1 hour
|
||||
- Description
|
||||
|
||||
- Cookie
|
||||
lpv500371
|
||||
- Duration
|
||||
1 hour
|
||||
- Description
|
||||
Description is currently not available.
|
||||
- Cookie
|
||||
\_gcl\_au
|
||||
- Duration
|
||||
3 months
|
||||
- Description
|
||||
- Cookie
|
||||
CLID
|
||||
- Duration
|
||||
1 year
|
||||
- Description
|
||||
- Cookie
|
||||
\_ga
|
||||
- Duration
|
||||
1 year 1 month 4 days
|
||||
- Description
|
||||
- Cookie
|
||||
\_gid
|
||||
- Duration
|
||||
1 day
|
||||
- Description
|
||||
- Cookie
|
||||
\_ga\_\*
|
||||
- Duration
|
||||
1 year 1 month 4 days
|
||||
- Description
|
||||
- Cookie
|
||||
\_clck
|
||||
- Duration
|
||||
1 year
|
||||
- Description
|
||||
- Cookie
|
||||
\_clsk
|
||||
- Duration
|
||||
1 day
|
||||
- Description
|
||||
- Cookie
|
||||
SM
|
||||
- Duration
|
||||
session
|
||||
- Description
|
||||
- Cookie
|
||||
MR
|
||||
- Duration
|
||||
7 days
|
||||
- Description
|
||||
- Cookie
|
||||
pardot
|
||||
- Duration
|
||||
past
|
||||
- Description
|
||||
- Cookie
|
||||
\_fw\_crm\_v
|
||||
- Duration
|
||||
1 year
|
||||
- Description
|
||||
- Cookie
|
||||
MSPTC
|
||||
- Duration
|
||||
1 year 24 days
|
||||
- Description
|
||||
Description is currently not available.
|
||||
|
||||
- Cookie
|
||||
visitor\_id\*
|
||||
- Duration
|
||||
1 year 1 month 4 days
|
||||
- Description
|
||||
- Cookie
|
||||
visitor\_id\*-hash
|
||||
- Duration
|
||||
1 year 1 month 4 days
|
||||
- Description
|
||||
- Cookie
|
||||
MUID
|
||||
- Duration
|
||||
1 year 24 days
|
||||
- Description
|
||||
- Cookie
|
||||
bcookie
|
||||
- Duration
|
||||
1 year
|
||||
- Description
|
||||
- Cookie
|
||||
ANONCHK
|
||||
- Duration
|
||||
10 minutes
|
||||
- Description
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
# Zero Trust and ISO 27001
|
||||
|
||||
[Zero Trust](../📚️%20Literature%20notes/Zero%20Trust.md) is a security principle that can be applied to systems and processes. [ISO 27001 A.13.2 Information transfer](../legacy/ISO%2027001%202013/ISO%2027001%20A.13.2%20Information%20transfer.md) is a method to manage security risks.
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue