The Security Questions That Don’t Apply to a SAP-Native Add-On

The Cloud Security Alliance’s Consensus Assessment Initiative Questionnaire, CSA CAIQ v4, runs to 261 questions across 17 control families. It is the structured form of the conversation an enterprise procurement team is trained to have with any new cloud SaaS vendor: where is the data, who can access it, how is it encrypted, what happens if something goes wrong. Where the reconciliation tool runs in the vendor’s cloud, the questionnaire is the gate that has to be cleared from a standing start. Where the tool is a SAP-native add-on deployed inside the customer’s SAP system, most of those 261 questions are answered by evidence the IT team has already filed. The architecture inherits the answers. The procurement cycle gets shorter because the questions either no longer apply or have already been resolved.

What an enterprise IT security review actually asks

The control families a serious vendor security review covers are stable across frameworks. The Cloud Security Alliance organises them through the CAIQ and the underlying Cloud Controls Matrix. The NIST Cybersecurity Framework groups them into Identify, Protect, Detect, Respond, Recover. ISO/IEC 27001 lists them as Annex A controls. UK GDPR adds the legal layer: Article 28 on processors and sub-processors, and Articles 44-49 on international transfers, with Article 33 covering breach notification.

Translated into the questions a procurement team writes down, the review usually covers ten categories.

Each line on that list represents a body of evidence the security team is required to collect and review. None of it is optional in a regulated environment, and in a SOX-scoped finance environment the access-control and audit-logging lines carry weight beyond the questionnaire itself.

Where an external reconciliation platform creates the security review

An external cloud reconciliation platform runs the reconciliation logic in its own infrastructure. To do that, it has to extract data from SAP. General ledger balances, subledger balances, transaction details, master data, currency rates: all of it is read from SAP on a schedule and held in the vendor’s cloud while the reconciliation runs. The data crosses a network boundary on the way out and again on the way back when results are written into SAP for audit and compliance.

That data path generates almost every category in the table above as a separate question to answer.

Residency and encryption each open as fresh conversations: where the extract sits, what ciphers protect it, who holds the keys. There is now a second disclosure list to maintain, because the vendor’s hyperscaler, monitoring provider, and any downstream services join the customer’s processing chain under UK GDPR Article 28. Egress becomes a control problem, because there is now a second platform from which a user can download the customer ledger. Disaster recovery requires a fresh BCDR plan because the platform sits outside the customer’s existing SAP recovery scope, with its own RTO, RPO, and test evidence. Incident response brings a second contractual notification clause and a second forensic-access route.

None of this is wrong. The reviewer is doing their job. The point is that each category is a fresh question, asked of an external platform that the SAP team has not previously approved, and the evidence has to be collected, read, and signed off by people who are not the reconciliation team.

What a SAP-native add-on inherits

A SAP-native add-on is deployed inside the customer’s SAP system. The reconciliation logic runs there. Nothing sits between SAP and the user, and the data does not cross a network boundary.

That removes some of the questions and inherits the answers to the rest.

Residency is whatever residency the customer’s SAP system already has. The IT team chose the data centre region, signed off on it, and listed it in the data map. Reconciliation does not change that.

The sub-processor list does not change. SAP’s existing sub-processor list for the customer’s instance still applies to SAP itself. There is no add-on sub-processor for the data path.

Existing SAP logins, role-based authorisations, and access-revocation flows still cover the reconciliation user. Users do not get a second identity or a second MFA flow, and there is no separate access-revocation process to maintain. When a user is offboarded in SAP, they are offboarded for reconciliation in the same step. The SOX ITGC access-control evidence already covers it.

Reconciliation data inherits SAP’s encryption, the same ciphers and the same key management.

The audit trail of approvals, rejections, reason codes, and supporting documentation stays inside SAP, visible to the team that already monitors it. The SIEM integration the IT security team already runs picks up the activity through the same channel.

There is no second download path to govern. Egress controls stay whatever SAP enforces.

The third-party assurance question shifts. The procurement team asking for a SOC 2 Type II report on the platform processing their data is asking for SAP’s, which sits in the customer’s existing trust evidence pack. BEST holds ISO 27001 certification for its own organisation, and that evidence sits alongside its SAP-certified add-on status in the procurement pack.

Patch cadence and vulnerability management lose the external-platform layer. There is no separate cloud infrastructure to patch on the add-on side. SAP’s own patch cadence remains, and is governed by the IT team that already governs it.

Disaster recovery and incident response inherit SAP’s plans, including the notification clauses and continuity tests already in place. The 72-hour breach notification clause under UK GDPR Article 33 already runs through the customer’s SAP processor relationship.

Three of the ten categories are simplified rather than removed: authentication, audit logging, and the third-party assurance question. The other seven either disappear or default to evidence the IT team has already filed.

How this plays out at audit

Vodafone has reported that their internal SOX audit requirements continue to be met, with auditors having direct access to BEST inside the SAP environment. The auditors review the reconciliation evidence in the system the SAP team already produces SOX evidence from, against the access controls that already sit in scope. Heineken Beverages runs 700+ monthly reconciliations through Vendor Recons at 99% auto-matching. The scale runs in the same SAP environment the customer’s audit programme already covers.

Both points sit on the same architectural choice: the audit programme stays where the SAP team has already evidenced it, because the data has not moved.

ISO 27001 in context

BEST holds ISO 27001 certification. It is the right baseline for an enterprise software vendor, and it covers the organisational controls a procurement team is entitled to expect: information security policy, supplier relationships, change management, incident response, the Annex A control set as a whole.

The architectural inheritance carries more weight in this argument, because it removes whole categories of question rather than answering them well. ISO 27001 is the organisational evidence that supports it. The SAP-certified add-on status, deployed inside the customer’s SAP system, is the architecture that makes the inheritance possible. Both belong in the procurement pack, with the architectural argument doing the heavier work.

Close

For a SAP-running enterprise mid-procurement on a reconciliation tool, the security review is not the slow part of the cycle when the tool runs inside the SAP system the IT team has already approved. The questions either fall away or land on evidence already on file. The reconciliation team gets to a contract conversation with the security team’s sign-off in hand rather than ahead of them. Book a demo to walk through the architecture against your current security review.