diff --git a/5.0/en/0x10-V1-Architecture.md b/5.0/en/0x10-V1-Architecture.md
index 21e175c57e..79cce75a18 100644
--- a/5.0/en/0x10-V1-Architecture.md
+++ b/5.0/en/0x10-V1-Architecture.md
@@ -5,15 +5,6 @@
 This paragraph contains documentation requirements that are pre-conditions for implementation and testing.
 
 Note that the documentation requirements here are a temporary solution, and it is yet to be decided how to organize them in the release. The requirements, that or not documentation requirements, are subject to be removed or moved.
-<!--
-Security architecture has almost become a lost art in many organizations. The days of the enterprise architect have passed in the age of DevSecOps. The application security field must catch up and adopt agile security principles while re-introducing leading security architecture principles to software practitioners. Architecture is not an implementation, but a way of thinking about a problem that has potentially many different answers, and no one single "correct" answer. All too often, security is seen as inflexible and demanding that developers fix code in a particular way, when the developers may know a much better way to solve the problem. There is no single, simple solution for architecture, and to pretend otherwise is a disservice to the software engineering field.
-
-A specific implementation of a web application is likely to be revised continuously throughout its lifetime, but the overall architecture will likely rarely change but evolve slowly. Security architecture is identical - we need authentication today, we will require authentication tomorrow, and we will need it five years from now. If we make sound decisions today, we can save a lot of effort, time, and money if we select and re-use architecturally compliant solutions. For example, a decade ago, multi-factor authentication was rarely implemented.
-
-If developers had invested in a single, secure identity provider model, such as SAML federated identity, the identity provider could be updated to incorporate new requirements such as NIST SP 800-63 compliance, while not changing the interfaces of the original application. If many applications share the same security architecture and thus that same component, they all benefit from this upgrade at once. However, SAML may not always remain the most suitable authentication solution - it might need to be swapped out for other solutions as requirements change. Changes like this are either complicated, so costly as to necessitate a complete rewrite, or outright impossible without security architecture.
-
-In this chapter, the ASVS covers the primary aspects of any sound security architecture: availability, confidentiality, processing integrity, non-repudiation, and privacy. Each of these security principles must be built in and be innate to all applications. It is critical to "shift left", starting with developer enablement with secure coding checklists, mentoring and training, coding and testing, building, deployment, configuration, and operations, and finishing with follow-up independent testing to ensure that all of the security controls are present and functional. The last step used to be everything we did as an industry, but that is no longer sufficient when developers push code into production tens or hundreds of times a day. Application security professionals must keep up with agile techniques, which means adopting developer tools, learning to code, and working with developers rather than criticizing the project months after everyone else has moved on.
--->
 
 ## V1.1 Secure Software Development Lifecycle
 
diff --git a/5.0/en/0x18-V10-Coding.md b/5.0/en/0x18-V10-Coding.md
index 728a256790..ef356ba5ba 100644
--- a/5.0/en/0x18-V10-Coding.md
+++ b/5.0/en/0x18-V10-Coding.md
@@ -84,7 +84,7 @@ Without proper synchronization, concurrent access to shared resources can result
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
-| **10.7.1** | [MODIFIED, MOVED FROM 1.11.3, LEVEL L2 > L3] Verify that only thread-safe types are used in multi-threaded contexts, or that non-thread-safe types are properly synchronized to prevent race conditions. | | | ✓ | 362 |
+| **10.7.1** | [MODIFIED, MOVED FROM 1.11.3] Verify that only thread-safe types are used in multi-threaded contexts, or that non-thread-safe types are properly synchronized to prevent race conditions. | | | ✓ | 362 |
 | **10.7.2** | [MODIFIED, MOVED FROM 1.11.2, LEVEL L2 > L3] Verify that concurrent access to shared resources is controlled using synchronization primitives (e.g., locks, mutexes, semaphores) to prevent race conditions and ensure atomic operations on these resources. | | | ✓ | 366 |
 | **10.7.3** | [MODIFIED, MOVED FROM 11.1.6] Verify that all access to shared resources is consistently checked and accessed in a single atomic operation to prevent Time-of-Check to Time-of-Use (TOC/TOU) race conditions, ensuring resource state consistency between check and use. | | ✓ | ✓ | 367 |
 | **10.7.4** | [ADDED] Verify that resource acquisition uses a consistent locking strategy to avoid circular dependencies and ensure forward progress, preventing both deadlocks and livelock scenarios. | | | ✓ | 833 |
diff --git a/5.0/en/0x19-V11-BusLogic.md b/5.0/en/0x19-V11-BusLogic.md
index fc4d1bb96d..fb8a6eeba0 100644
--- a/5.0/en/0x19-V11-BusLogic.md
+++ b/5.0/en/0x19-V11-BusLogic.md
@@ -30,7 +30,7 @@ Ensure that a verified application satisfies the following high-level requiremen
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **1.11.1** | [DELETED, NOT IN SCOPE] | | | | |
 | **1.11.2** | [MOVED TO 10.7.2] | | | | |
-| **1.11.3** | [DELETED, DUPLICATE OF 11.1.6] | | | | |
+| **1.11.3** | [MOVED TO 10.7.1] | | | | |
 | **1.11.4** | [ADDED] Verify that expectations for business logic limits and validations are clearly documented including both per-user and also globally across the application. | | ✓ | ✓ | |
 
 ## V11.1 Business Logic Security
@@ -44,7 +44,7 @@ Business logic security is so individual to every application that no one checkl
 | **11.1.3** | [MODIFIED, MERGED FROM 11.1.5] Verify that business logic limits and validations are implemented as per the application's documentation. | ✓ | ✓ | ✓ | |
 | **11.1.4** | [MOVED TO 11.2.2] | | | | |
 | **11.1.5** | [DELETED, MERGED TO 11.1.3] | | | | |
-| **11.1.6** | [SPLIT TO 10.7.1, 10.7.2, 10.7.3] | | | | |
+| **11.1.6** | [MOVED TO 10.7.3] | | | | |
 | **11.1.7** | [MOVED TO 7.2.4] | | | | |
 | **11.1.8** | [MOVED TO 7.2.5] | | | | |
 | **11.1.9** | [ADDED] Verify that "atomic transactions" are being used at the business logic level such that either a business logic operation succeeds in its entirety, or it is rolled back to the previous correct state. | | ✓ | ✓ | |
@@ -54,7 +54,7 @@ Business logic security is so individual to every application that no one checkl
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
-| **11.2.1** | [MOVED FROM 11.1.2, LEVEL L1 > L3] Verify that business logic processes require realistic human timing, preventing excessively rapid transaction submissions. | | | ✓ | 799 |
+| **11.2.1** | [MODIFIED, MOVED FROM 11.1.2, LEVEL L1 > L3] Verify that business logic processes require realistic human timing, preventing excessively rapid transaction submissions. | | | ✓ | 799 |
 | **11.2.2** | [MODIFIED, MOVED FROM 11.1.4, LEVEL L1 > L2] Verify that anti-automation controls are in place to protect against excessive calls to application functions that could lead to data exfiltration, garbage data creation, quota exhaustion, rate limit breaches, denial of service, or overuse of costly resources. | | ✓ | ✓ | 770 |
 
 ## References
diff --git a/5.0/en/0x50-V50-Web-Frontend-Security.md b/5.0/en/0x50-V50-Web-Frontend-Security.md
index bbda393c1f..3494dce8fb 100644
--- a/5.0/en/0x50-V50-Web-Frontend-Security.md
+++ b/5.0/en/0x50-V50-Web-Frontend-Security.md
@@ -24,7 +24,7 @@ HTTP responses must include security headers to set rules to how browsers can se
 
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
-| **50.2.1** | [MODIFIED, MOVED FROM 14.4.3] Verify that every HTTP response includes a Content-Security-Policy header to reduce the risk of malicious JavaScript. The directives object-src 'none' and base-uri 'none' must be defined. For an L3 application, a per-response policy with nonces or hashes must be defined. | | ✓ | ✓ | |
+| **50.2.1** | [MODIFIED, MOVED FROM 14.4.3, LEVEL L1 > L2] Verify that every HTTP response includes a Content-Security-Policy header to reduce the risk of malicious JavaScript. The directives object-src 'none' and base-uri 'none' must be defined. For an L3 application, a per-response policy with nonces or hashes must be defined. | | ✓ | ✓ | |
 | **50.2.2** | [GRAMMAR, MOVED FROM 14.4.4] Verify that all responses contain a X-Content-Type-Options: nosniff header field. | ✓ | ✓ | ✓ | 116 |
 | **50.2.3** | [MODIFIED, MOVED FROM 14.4.5] Verify that a Strict-Transport-Security header field is included on all responses and for all subdomains, such as Strict-Transport-Security: max-age=31536000; includeSubdomains. | ✓ | ✓ | ✓ | 523 |
 | **50.2.4** | [MODIFIED, MOVED FROM 14.4.6] Verify that an suitable Referrer-Policy header is included to prevent sensitive information in the URL from being exposed to untrusted parties via the Referer header. | ✓ | ✓ | ✓ | 116 |