SAP integration and compliance
The regulatory requirements the SAP integration produces evidence for, the evidence each feature leaves behind, and the flags you need.
The SAP integration supports regulatory requirements by producing evidence about SAP change control, authorisations and operations. It does not make you compliant on its own: TENSOR supports or provides evidence for the requirements below; it does not fulfil them.
BAIT is cited with its historical numbering, as in TENSOR's compliance mapping.
Preview module
The SAP integration has been tested with SAP-shaped fixture data only. Run a pilot against a non-productive SAP landscape before you rely on it for audit evidence. See Availability.
Requirement mapping
| Requirement | TENSOR feature | Evidence produced |
|---|---|---|
| BAIT §7/§8 (historical) and MaRisk AT 7.2: separation of duties in application development and change | Transport SoD rules; separate schedule and confirm rights; force-import right | Audit rows for every refusal, override and confirmation |
| BAIT 5.4 (historical): Berechtigungskonzept | SAP role assignments, user mapping, 53-rule SoD risk catalog | SoD violations per connection; SAP risks in the Berechtigungskonzept export |
| BAIT 8/9 (historical): application changes and IT operations | Transports as Normal Changes with approval, scheduling and PROD closure | Change record per transport; sealing audit row at PROD import; drift ledger |
| DORA Art. 8: identification of ICT assets | SAP systems, clients and HANA databases as CIs | Versioned CI records |
| DORA Art. 17: ICT incident management | CCMS alerts create linked incidents | Incidents with SAP source and CI link |
| DORA Art. 12: backup and restoration (SAP-08 specification) | HANA backup and replication status on the CI | HANA status history, restore-test date |
| Retention of change and ticket history for DORA- and BAIT-regulated tenants | Sealed SolMan archive | Batch content hash in the audit chain; exported manifest |
| DSGVO (GDPR) | PII classification of SAP usernames, masking, local credentials, PII-free agent logs | Masked archive fields; audit of secret access |
Limits to state alongside the evidence
The evidence is only as complete as the capabilities behind it. When you present it to an auditor, note these current limits from the availability table:
- Separation of duties on transports is partially available. Developer-is-not-approver and developer-is-not-importer are enforced; approval-stage separation (the DEV-to-QA approver not approving QA-to-PROD) is not yet enforced.
- SAP authorisations are partially available. Assignments and findings are visible, but SAP-to-TENSOR user mappings cannot yet be created in the UI.
- Release gating and automatic import from TENSOR are planned. TENSOR records transports that moved ahead of their Change as drift; it does not stop SAP from moving them.
- EarlyWatch Alert evidence is uploaded manually; agent upload is planned.
- The SolMan archive accepts CSV only; XLSX is planned.
How the evidence is protected
- Audit chain. Every SAP mutation writes one hash-chained audit row in the same transaction — including SoD refusals, collision overrides, import confirmations, drift events and migration mode changes. A PROD import that closes a Change writes a sealing audit row.
- Sealed archive. Each SolMan import batch is sealed with the SHA-256 hash of its content, archive records can never be edited or deleted, and each batch can be exported as a CSV with a signed manifest.
- Personal data. SAP usernames and role assignments are classified as identifying personal data. SolMan archive requesters and assignees are masked for roles without de-masking rights. RFC and HANA credentials never leave the agent host, and agent logs carry no credentials, SAP usernames, transport owners or raw payloads.
- Secrets. OAuth client secrets and the agent's signing secret are stored encrypted, and every access to the signing secret is audited.
Which flags you need
| Flag | Needed for |
|---|---|
sap_integration | Everything in the SAP integration. Default off, not sticky. |
bait_berechtigungskonzept_export | The Berechtigungskonzept export that includes the SAP SoD catalog, in addition to sap_integration. |
Generating the Berechtigungskonzept also needs the permission reporting.berechtigungskonzept.export. For every flag and its effect, see the toggle catalog. For the platform-wide SoD rules, see segregation of duties.
Scope at first launch
At first launch, the SAP module is scoped to named landscapes, bounded evaluations or coexistence with Solution Manager. It is not positioned as a replacement for SolMan ChaRM across every landscape. See SolMan migration.
SolMan migration
Preserve Solution Manager ChaRM and ITSM history in a sealed archive, run TENSOR in parallel with Solution Manager, and cut over against a checklist computed from live data.
Guides for setup and Basis administrators
Step-by-step guides to switch on the SAP integration, register systems, define landscapes, run the connector agent and keep HANA and EarlyWatch Alert evidence current.