Configuration and Security Analysis (CSA) helps organisations evaluate the compliance posture of their SAP landscape by running automated checks against collected configuration data. These checks identify services that require attention, highlight deviations from recommended settings, and provide guidance on remediation actions.
However, every organisation has unique security, compliance, and operational requirements. While SAP-delivered checks cover many standard recommendations and security baselines, they may not address all company-specific controls.
To address this need, CSA enables customers to create custom checks and organise them into custom policies. This allows organisations to translate their internal security requirements into automated, measurable validations across their SAP environment.
What Are Custom Checks?
A Custom check is a customer-defined validation rule that is evaluated against data gathered centrally in your SAP Cloud ALM tenant and stored in Configuration Stores (CCDB tables) for easy addressing. It enables organizations to validate configuration values, security settings, and other technical conditions that are relevant to their business requirements.
Note: Custom checks are currently supported per service type.
They can be created in the Configuration and Security Analysis – Validation application by navigating to:
Button Configuration → Button Checks -> Button Configuration (Drop down menu) → Under tab Custom Checks -> Button Create
Note: Alternately, you can access custom checks by navigating to Button Configuration-> Click arrow and navigate to the next level -> Under tab Custom Checks -> Button Create
A custom check can be used to define:
- The configuration settings to validate
- The expected compliant value or condition
- The corresponding non-compliant condition
- The systems or system roles where the check should apply
- The severity of a violation
- Follow-up actions, such as creating alerts, tickets, or notifications
- Context and further information (through the free text description field).
Once activated and synchronised, the custom check is included in productive check calculations and contributes to the overall compliance results.
Required Fields for Creating a Custom Check
Before creating a validation rule, several fields must be maintained.
Check ID | Unique identifier (e.g. SEC-001) | Mandatory |
Check Name | Human-readable label | Mandatory |
Topic | Security / Performance / Compliance … | Mandatory |
Severity | Critical / Warning / Information | Mandatory |
Store Name | All data stores associated with the selected service type | Mandatory |
Check Description | Human-readable text |
|
Filter By | System Role / System ID |
|
Validation Logic | Rule expression evaluated at runtime | Mandatory |
The available fields in the validation-rule table depend on the selected store name. The store represents the source of collected configuration data against which the rule is evaluated.
After defining the compliant condition, CSA can automatically generate the opposite condition by selecting:
- Generate Non-Compliance Rule
This simplifies the creation of rules for items that do not meet the compliance definition.
Creating a Custom Check
Example1: For SAP S/4HANA
Consider an example for the Private Cloud Solution service type SAP S/4HANA.
Organisation has password policy to enforce inclusion of special characters for Production and Test systems, but this is not needed to be enforced on Development systems.
- abap/ext_debugging_possible (Equal to) 2 – For Production systems
- abap/ext_debugging_possible (Equal to) 0 – For Development systems
This parameter controls whether external debugging is permitted in an ABAP system. In a development system, a value of 0 (which allows external debugging) is acceptable and practical — developers need to debug programs remotely and interactively. In a production system, the recommended value is 2, which disables external debugging entirely to prevent un-authorised inspection or manipulation of running processes.
There are two possible approaches.
Option 1: Use an Existing SAP-Delivered Check
- Use the SAP-delivered check: ABAP-CHANGE-0008-1
- Then restrict its scope to only Production, Development and/or Test systems.
- This approach ensures that the SAP baseline requirement is evaluated only where it is applicable.
Option 2: Create a Custom Check for Development Systems
Create a customer-specific check that validates the parameter value `0` only for development systems.
This provides flexibility where an organisation has formally approved different security settings for specific system roles.
Step 1: Maintain the General Information
In the Custom Check configuration, maintain the required information in the General tab.
Example values:
- General Information Tab
- Check Name: Allow External Debugging in Development system
- Check ID: SEC-DEV-001
- Topic: Protect Production System Against Changes
- Severity: Warning or Information, depending on company policy
- Store Name: ABAP_INSTANCE_PAHI
- Details Tab
- Check Description: Validates the external debugging for development systems
The store `ABAP_INSTANCE_PAHI` contains profile parameter information for ABAP instances.
Step 2: Define the Scope
In the Scope tab, define where the custom check should run.
A check can be applied to:
- The entire applicable landscape
- A particular service
- A system role, such as Development, Test, or Production
- A specific system
For this example, assign the check only to:
- Role: Development
This ensures that the custom rule does not affect test or production systems.
Step 3: Define the Validation Rule
The Validation tab is where the compliance and non-compliance definitions are maintained.
For the development-system exception, define the compliant condition as follows:
- Name: abap/ext_debugging_possible
- Value: 0
This means that a development system is considered compliant when:
- abap/ext_debugging_possible = 0
After defining the compliant rule, select: Generate Non-Compliance Rule
CSA automatically generates the non-compliance definition for records that do not meet the expected condition.
Note: By clicking on `Add Rule` multiple rules can be added.
Handling Exceptional Conditions
In addition to compliant and non-compliant rules, CSA allows you to define how exceptional conditions should be handled. These can include:
- Store not found
- Item key not found
- Item value does not match either the compliance or non-compliance rule
- Record is outdated
These conditions should be carefully defined because they determine how incomplete, missing, or stale data is represented in the final validation result.
After creating the rule, select Create to save the custom check.
Step 4: Test and Activate the Check
Before using the check productively, use the Test Check functionality to validate the rule against the currently available data.
This helps confirm that:
- The correct configuration records are selected.
- The rule logic works as expected.
- The scope is correctly assigned.
- The expected systems are marked compliant or non-compliant.
The Last Test Result option displays the result of the latest test calculation.
Once the results are correct, activate the check. The active check will then be included in the next productive check calculation.
Custom checks can be modified and tested repeatedly until the desired validation outcome is achieved.
Step 5: Configure Events and Follow-Up Actions
In the Events tab, users can associate the check with downstream actions. For example, a non-compliant result can trigger one or more of the following:
- Create Alert
- Send Email
- Start Operation Flow
- Send Chat Notification
- Create Ticket
This enables organisations to move from passive reporting to automated compliance management and remediation workflows.
Example2: Password Policy Check for SAP Identity Authentication Service
Custom checks can also be created for Public Cloud solutions, such as SAP Cloud Identity Services – Identity Authentication.
Password policy requirements often differ between organizations. For example, a company may require stronger password controls than those defined in a standard baseline.
The following example defines a password-policy check.
- ID: SEC-042
- Name: Password Policy
- Topic: Security
- Severity: Critical
- Status: Active
- Scope: Role->Production
For SAP Identity Authentication, select the store:
- IAS_PASSWORD_POLICIES
When this store is selected, the relevant password-policy parameters become available in the Validation section.
An organisation may define their custom corporate requirements for minimum password length, maximum unused period and failed sign in attempts.
The intended compliance logic is:
- PASSWORD_POLICY_NAME (EQUALS) `Password Policy`
- MINIMUM_PASSWORD_LENGTH (Greater or Equals) 8
- USER_INACTIVITY (Greater or Equals) 2
- Failed Sign In Attempts (Equals) 3
All conditions must be true for the result to be considered compliant.
Note: The exact operators must reflect the organisation’s password-policy requirement.
The non-compliance rule can then be generated automatically using the Generate Non-Compliance Rule option.
Once the rule has been created, test the check, review the results, and activate it for productive compliance calculations.
Organisations can create any number of custom checks to address internal requirements, industry-specific controls, and regulatory obligations.
Check Evaluation and Compliance
Check calculations are performed daily against data stored in the configuration stores. Once processed, the results can be reviewed in the overview page of the Configuration and Security Analysis – Validation application.
Why Are Policies Important?
A custom check represents a single technical validation. In large SAP landscapes, organizations may have hundreds of checks covering security, performance, availability, configuration, and compliance.
Policies provide a structured way to group these individual checks into meaningful business or compliance objectives.
By grouping technical checks into clear policies, organizations can bridge the gap between low-level IT configuration details and executive, audit, or regulatory requirements.
Types of Policies in CSA
CSA supports SAP-delivered policies as well as customer-defined custom policies.
Some examples of SAP-delivered policies include:
- SAP Security Baseline Template policy (as per SAP KBA 2253549 – The SAP Security Baseline Template)
- Security Recommendations policy
- SAP Certification Expiration policy
- SAP Security Notes policy
Customers can also create custom policies that reflect their own internal compliance frameworks.
Both SAP Policies and Custom Policies can be viewed by navigating to Button Configuration → Button Policies.
There are two main policy types:
- Single Policy
- Composite Policy
Single Policy
A Single Policy groups related checks that belong to one service type and contribute to a common compliance objective.
For example, a single policy named SAP S/4HANA Security Baseline may include checks for:
- SAP* user configuration
- Password parameters
- Remote function module restrictions
- RFC Gateway access control list configurations
- Audit-log settings
- Profile parameter values
Note: A single policy is always associated with a particular SAP service type.
Creating a Single Policy
To create Policies, navigate to Button Configuration → Button Policies -> Button Custom Policies -> Button Create
A single policy can be created in two ways:
- By Name
The user selects checks directly by their check names for the chosen service type. This approach is useful when a specific and stable set of checks should be included in the policy.
- By Rule
The policy dynamically includes checks that meet defined selection criteria.
For example, a rule can include all checks that match:
- Topic: Security
- Severity: Critical
- Status: Active
This method is useful as the current and future defined checks will be automatically included by the dynamic criteria thereby reducing maintenance and enhancing end user coverage.
Composite Policy
A Composite Policy is a higher-level policy that combines multiple single policies, other composite policies, SAP-delivered policies, and custom policies.
Unlike a single policy, a composite policy is not limited to one service type. This makes it suitable for enterprise-wide compliance frameworks.
For example, a composite policy named Corporate Security Standard may include:
- SAP S/4HANA Security Baseline
- SAP Identity Authentication Password Policy
- SAP Security Notes Compliance
- SAP Certification Expiration
- Cloud Security Recommendations
Creating a Composite Policy
Composite policies can also be created in two ways.
- By Name
The user explicitly selects single and composite policies by name.
- By Rule
The user defines criteria that determine which policies should be included. This approach supports flexible, rule-based policy structures and helps maintain larger compliance frameworks.
Policy Configuration
To configure policies, navigate to:
Operations Work Center → Configuration and Security Analysis – Validation application → Button Configuration → Button Policies
From this area, users can view SAP-delivered policies and create custom policies.
The following fields are used when creating a custom policy:
Field | Description | Mandatory |
Policy Name | Human-readable name of the policy | Yes |
Policy Type | Single or Composite | Yes |
Service Type | SAP service type for which the policy is created | Required for Single Policy |
Policy Description | Description of the policy purpose | No |
Selection Type | By Name or By Rule | Yes |
Key Concepts for Checks and Policies
Grouping
A single policy bundles checks that share a common objective, such as a security baseline, password policy, or audit-readiness standard.
Evaluation
All checks included in a policy are evaluated during compliance calculation. The results are aggregated and displayed as the policy’s overall compliance status.
Reusability
A check can belong to multiple policies. For example, a password-policy check can be included in:
- A security baseline policy
- An internal corporate security policy etc..
Granularity
Although policies provide a high-level compliance view, individual check results remain visible. This allows administrators to identify the exact setting, system, or configuration item that caused a policy violation.
Viewing Policy Results
Custom policies and SAP-delivered policies are visible in the compliance dashboard on the Validation Overview page.
The dashboard provides a centralized view of:
- Compliance status across the monitored SAP landscape
- Policy-level compliance distribution
- Check-level deviations
- Non-compliant systems and services
- Severity of findings
When creating a policy, users can mark it as the default policy.
When users navigate to the Validation Overview page and select Validation Policy, the default policy is preselected automatically.
The compliance results for all checks included in the selected policy are then displayed in the results table, including the compliance distribution across the monitored landscape.
Conclusion: Checks and Policies Work Together
Custom checks and policies provide organizations with the flexibility to convert their own security and compliance requirements into automated technical validations.
A check is the atomic unit of validation. It verifies one specific technical condition, such as a profile parameter value, password-policy setting, certificate expiration date, or audit-log configuration.
A policy is the business-level structure that groups related checks into a meaningful compliance objective. Policies help organizations assess compliance against internal standards, security baselines, industry frameworks, and regulatory requirements.
Together, checks and policies provide the following benefits:
- Continuous monitoring of security and configuration compliance
- Support for company-specific requirements beyond SAP-delivered content
- Clear visibility into non-compliant systems and configuration settings
- Automated alerts, tickets, and remediation workflows
- Easier audit preparation and evidence collection
- Reusable compliance frameworks across different SAP services and landscapes
- Executive-level compliance reporting without losing technical detail
By creating tailored checks and organizing them into well-defined policies, organizations can establish a scalable and continuous compliance-management process across their SAP landscape.
Please refer the following blog which also explains Custom checks in detail.
You can also check the recent topics on Configuration and Security Analysis here.