Remove alerting as out of scope to resolve #2630

5.0/en/0x15-V7-Error-Logging.md

@@ -40,15 +40,16 @@ Logging events which are security relevant is an important mechanism for being a
 
 This section will briefly discuss the types of events to log but deliberately does not go into too much detail. It will be necessary to refer to external detailed guidance such as the OWASP Logging Cheat Sheet and the OWASP Application Logging Vocabulary Cheat Sheet for specific implementation details.
 
+Note also that alerting is likely to be a separate process and system. As such, whilst logging the correct events if in considered in scope for ASVS, correlating and alerting on these events is not.
+
 | # | Description | Level | CWE |
 | :---: | :--- | :---: | :---: |
 | **7.2.1** | [MODIFIED] Verify that all authentication operations are logged including both successful and unsuccessful attempts. Additional metadata such as type of authentication or factors used should also be collected. | 2 | 778 |
 | **7.2.2** | [MODIFIED] Verify that failed access control attempts are logged. For L3 this must include logging all access control decisions. | 2 | 285 |
 | **7.2.3** | [MODIFIED, MOVED FROM 7.1.3] Verify that the application logs attempts to bypass the security controls defined in the design documentation such as input validation. | 2 | 778 |
 | **7.2.4** | [MODIFIED, MOVED FROM 11.1.7] Verify that the application monitors for unusual events or activity from a business logic perspective. | 2 | 754 |
-| **7.2.5** | [MODIFIED, MOVED FROM 11.1.8] Verify that the application has configurable alerting when unusual or malicious activity is detected. | 2 | 390 |
+| **7.2.5** | [MODIFIED, MOVED FROM 8.3.5] Verify that accessing sensitive data is logged (without logging the sensitive data itself) if this is required by relevant data protection requirements. | 2 | |
 | **7.2.6** | [MODIFIED, MOVED FROM 9.2.5] Verify that the application logs security control failures such as backend TLS failures. | 3 | 778 |
-| **7.2.7** | [MODIFIED, MOVED FROM 8.3.5] Verify that accessing sensitive data is logged (without logging the sensitive data itself) if this is required by relevant data protection requirements. | 2 | |
 
 ## V7.3 Log Protection
 

5.0/en/0x16-V8-Data-Protection.md

@@ -52,7 +52,7 @@ Note: Privacy regulations and laws, such as the Australian Privacy Principles AP
 | **8.3.2** | [DELETED, NOT IN SCOPE] | | |
 | **8.3.3** | [DELETED, NOT IN SCOPE] | | |
 | **8.3.4** | [DELETED, MERGED TO 1.8.1] | | |
-| **8.3.5** | [MOVED TO 7.2.7] | | |
+| **8.3.5** | [MOVED TO 7.2.5] | | |
 | **8.3.6** | [DELETED, NOT PRACTICAL] | | |
 | **8.3.7** | [DELETED, COVERED BY 1.8.2] | | |
 | **8.3.8** | [LEVEL L2 > L3] Verify that sensitive personal information is subject to data retention classification, such that old or out of date data is deleted automatically, on a schedule, or as the situation requires. | 3 | |

5.0/en/0x19-V11-BusLogic.md

@@ -32,7 +32,7 @@ Business logic security is so individual to every application that no one checkl
 | **11.1.5** | [DELETED, MERGED TO 11.1.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.8** | [DELETED, NOT IN SCOPE] | | |
 | **11.1.9** | [ADDED] Verify that 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. | 2 | |
 | **11.1.10** | [ADDED] Verify that very high-value business logic flows are restricted with multi-user approval to prevent unauthorized or accidental actions. This could include but is not limited to large monetary transfers, contract approvals, access to critical nuclear facility operations, healthcare record modifications, access to classified information, or safety overrides in manufacturing. | 3 | |