A consumer-goods company puts six applications under one control framework
Six business applications around SAP were each governed on their own. One matrix of 91 controls and 103 segregation-of-duties rules, tested against real user data, showed what to fix first.
From our own project and product work. Client names and identifying details are removed, and some figures are rounded.
The situation
A large consumer-goods company runs SAP as its book of record. Around it sit six other applications: procurement, export documents, warehousing, transport, sales to distributors, and sales from distributors to retailers. Access to each was governed on its own. Nobody could say which controls failed everywhere, where one person held two duties that should be split, or what evidence was still owed.
What we did
- Assess. We assessed each application against the company's own IT policies: access, assets, cryptography, network, operations and data loss. That gave 479 control records.
- One matrix. We built one catalogue of 91 controls in five IT general control domains, referenced to COBIT, and gave every application a row for every control. Anything never asked about is marked Not assessed, so a gap can never read as compliance.
- Functions, not role names. Segregation-of-duties rules were written between business functions, so a rule can cross from one application into SAP.
- Test on real users. Every rule was tested against the user-to-role data, with shared, generic and vendor accounts counted separately.
- Fold in evidence. Walkthroughs, questionnaires and security test reports updated the records, each change quoting its source.
Results
| Measure | Result |
|---|---|
| Controls in the catalogue | 91, in 5 domains |
| Matrix rows | 546 (6 applications × 91 controls) |
| Coverage gaps made visible | 67 application-control pairs never assessed |
| Records with a conclusion | Up from 25.1% to 33.6% after evidence |
| Segregation-of-duties rules | 103: 78 within one application, 25 across applications |
| Rules ready to load into SAP's access risk rule set | 53 |
| Evidence requests | About 830, each with an owner |
What we found
- No periodic access review in any of the six applications, although written answers said there was one.
- In one sales application, nearly 12,000 accounts were active and three in four had never logged in. In another, about 4,300 accounts existed for about 1,300 active distributors.
- In procurement, one shared support ID held 162 of 177 access groups.
- In the warehouse, the person who tests quality could also approve it.
- A field sales app ran on one password shared by about 2,600 users, so no action could be traced to a person.
- One application had 30 roles and 29 profiles where the business could name 7 role types. We proposed 17.
- Residual risk stayed equal to inherent risk on 99 of 103 rules, because no compensating control had been shown to work.
What changed
- From six assessments to one matrix. Estate-wide questions now have estate-wide answers.
- From role names to functions. Conflicts that cross into SAP can be written down and tested.
- From assertion to evidence. Ratings moved on evidence, and mitigation was never assumed.
- Theirs to run. The company's team can maintain the register and re-run the tests when access changes.
Products and services
Our digital, cyber and IT risk team ran this work. CompliBear can monitor the same controls every day. See also segregation of duties across applications.