Citations: ICFR

FireFighter access is granted only for the minimum necessary period required to perform the activity.

Controllers and Owners of FireFighter accounts are reviewed annually to ensure proper oversight.

Access to request FireFighter accounts is restricted to authorized personnel only.

FireFighter accounts are regularly assessed for validity and continued necessity.

User accounts are deactivated within five working days after the individual is marked as a leaver in the identity system.

The interface between target systems and the Identity & Access Management (CIDM) system is continuously monitored for errors.

Any activity performed after a contract termination date must be discovered and escalated for assessment.

Access entitlements for users who change job responsibilities are reviewed to ensure they are appropriate for the new role.

Minimum Security Baselines (MSBs) for password settings are defined and implemented.

System password configuration deviations from the SAP Security Baseline are automatically monitored and addressed.

Exceptions to security baselines must be documented, time-bound, and approved by the IT security governance body.

Access to generic account credentials must be maintained in a controlled environment (e.g., LAAM Safe) and strictly limited.

Access to generic account login credentials is reviewed at least annually to ensure continued validity.

Generic accounts are periodically reviewed to ensure they are registered in the IAM tool and have an active owner.

Completeness of the generic account inventory is ensured by reconciling IAM records against the target system.

Every change record must include an appropriate description of the change being implemented.

System changes must be reconcilable with corresponding records in the ITSM solution.

A formal impact assessment is performed and documented for every change.

For relevant changes, a formal code review is performed and documented.

Changes are adequately tested based on their criticality and potential impact.

All changes are tested in a non-production environment prior to being implemented in production.

Changes must be approved by the appropriate level of management as per the defined process.

Changes are moved to production only after all relevant approvals have been obtained.

Segregation of Duties rules are followed during the change approval and implementation process.

Roles with critical access to the change management system are strictly restricted.

Emergency changes require approval by management or a delegate, including functional owners.

Documentation and testing for emergency changes must be updated retrospectively within 10 working days.

The justification for using the emergency change process must be confirmed within 10 working days.

Scenarios for direct changes in production are clearly defined and exceptions are followed up.

Approvals for unlocking systems for direct changes are documented, and systems are locked immediately after completion.

Software updates and release notes from vendors are assessed for impact before implementation.

Minimum Security Baselines (MSBs) are defined and implemented for infrastructure components.

Deviations from infrastructure security baselines are periodically monitored and addressed based on criticality.

Exceptions to infrastructure security baselines must be documented and approved by the security governance body.

Access to edit or delete the security audit logs is strictly prohibited.

Access to modify the configuration of audit logs is restricted to authorized personnel only.

Critical events are recorded in the security audit log and stored for a minimum of two years.

Security audit logs must be active and monitored for completeness (no missing critical entries).

Events recorded in the security audit logs are reviewed and assessed for potential security risks.

An inventory of technical objects that require active monitoring is maintained and updated.

Automated processes and interfaces are monitored to identify critical errors or downtime in a timely manner.

IT support personnel follow up on and address critical errors or unexpected downtimes in a timely manner.

Security notifications and upgrades from vendors are regularly reviewed to identify required patches.

Security patches are assessed for impact and documented before being implemented in the environment.

Exceptions for not applying critical security patches must be documented and approved by the governance body.

Access requests undergo a review by role approvers and SoD champions to manage Segregation of Duties risks.

The SoD Dashboard is regularly monitored, and conflicts are addressed within defined timelines.

Periodic reviews of users with mitigated SoD risks are conducted to ensure controls remain effective.

New and custom transaction codes are evaluated to ensure they do not introduce SoD risks.

New and existing roles are assessed to prevent SoD risks and ensure no prohibited actions are permissible.

Vendor SOC 1 Type 2 reports are reviewed on time, and all Complementary User Entity Controls (CUECs) are identified and implemented.