How should security teams approach a Greenfield SAP S/4HANA implementation when they want a clean core without carrying legacy risk forward?

Rebuilding SAP S/4HANA as a control decision, not just an upgrade decision

A Greenfield SAP S/4HANA programme is most secure when the team treats it as a reset of business process, data, and access assumptions. The point is not only to modernise the platform, but to decide which old behaviours should never be reintroduced. That matters because SAP environments often accumulate exception logic, overextended roles, and integration dependencies that survive long after the original business reason has disappeared.

Security teams should therefore define the security baseline before design choices harden into configuration. That means agreeing where sensitive data will live, which processes are genuinely in scope, and how access will be granted, tested, and reviewed in the new model. The clean-core goal is strongest when it is tied to governance, segregation of duties, and a deliberate reduction in custom code and privileged access paths. NIST Cybersecurity Framework 2.0 is useful here because it frames the programme as a lifecycle control problem, not a one-time technical build. In practice, many security teams discover legacy risk only after old approvals, emergency access habits, and hidden interface assumptions have already been recreated in the new system.

What a clean-core implementation needs to lock down first

clean core is not a slogan for using fewer SAP features. It is a discipline for separating standard process from business-specific exceptions so that the platform remains easier to govern, test, and upgrade. In a Greenfield implementation, the first security question is whether a requirement truly belongs in the core, or whether it should sit in an adjacent workflow, control layer, or integration boundary. That distinction affects auditability, change velocity, and how much inherited complexity returns through the back door.

Security teams should start by mapping the minimum set of processes, roles, and interfaces that are required for day-one operation. From there, they can define control points around master data, privileged access, interface authentication, logging, and change approval. The practical aim is to keep business logic standard wherever possible, because every custom object expands the surface that must be tested and supported.

• Standardise process design before allowing local exceptions.
• Validate that each role has a current business owner and a review cadence.
• Treat integrations as trust boundaries, not as plumbing.
• Test whether master data quality supports the target controls, not just the target workflow.
• Use the implementation to remove obsolete access paths rather than migrate them.

This is where governance and implementation have to stay aligned. If the project team cannot explain why a deviation from standard exists, the deviation usually becomes permanent technical debt. NIST SP 800-53 Rev. 5 Security and Privacy Controls is relevant because the question is ultimately about enforcing control discipline across access, configuration, logging, and change. This guidance breaks down when an organisation calls something “clean core” while still recreating legacy approvals, bespoke authorisations, and brittle point-to-point integrations in disguise.

Where Greenfield clean core decisions usually get complicated

Tighter standardisation often increases short-term change pressure, requiring organisations to balance speed of delivery against the cost of exception handling. That tradeoff shows up most clearly when the business wants process uniqueness preserved even though the programme is meant to simplify the landscape.

One common edge case is that a process can look harmless in business terms but still create a security burden through approvals, segregation rules, or downstream reporting. Another is that integration simplification can expose hidden reliance on legacy middleware, service accounts, or manually handled files. In both cases, the cleaner design is often the safer one, but only if the organisation is willing to retire old workarounds rather than re-platform them unchanged. The consensus view is that fewer customisations generally improve maintainability; the open question is how much exception handling a business can absorb before it starts rebuilding the same fragility elsewhere.

Clean-core projects also struggle when teams assume that standard SAP configuration alone will eliminate risk. It will not. Data migration, role design, interface trust, and testing discipline still determine whether the new environment is actually lower risk than the old one. The strongest programmes use the Greenfield moment to remove unused privileges, obsolete objects, and duplicate approval paths before they become embedded in the target operating model.

Risk and Threat Considerations

A Greenfield SAP S/4HANA build can reduce inherited risk, but it can also recreate it at scale if legacy process exceptions, overprivileged access, and weak interface assumptions are copied into the new design. The main exposure is not the new platform itself, but the temptation to preserve old behaviour under the label of business continuity.

Failure mechanism: Legacy risk materialises when teams migrate roles, approvals, custom code, or integration patterns without re-validating whether they still satisfy least privilege, segregation of duties, and trust-boundary requirements. That often leads to excessive access, hidden dependencies, and control gaps that only become visible after cutover or during audit.

Impact: The result can be persistent over-entitlement, weak traceability, harder remediation after go-live, and a system that is technically new but operationally burdened by the same exposure profile as the old estate.

Practitioner Guidance

What to prioritise: Treat the business process model, role model, and integration map as security artefacts, not just implementation outputs. If those three are not aligned early, the clean-core target will usually be compromised by later exceptions.

What to verify: Confirm that every requested deviation has a business owner, an expiry condition, and a reason that still holds in the target design. Also verify that the migration plan removes obsolete access and interfaces instead of preserving them for convenience.

Common mistake: Teams often focus on reducing custom code while leaving privilege design and interface trust unchanged. That creates a system that looks simplified but still carries the old control failures in a different form.

Practitioner takeaway: The strongest clean-core outcomes come from refusing to equate “move to S/4HANA” with “carry forward the old operating model”; the security win is in eliminating the assumptions that made the legacy environment hard to govern.

Related resources from NHI Mgmt Group

• How should security teams approach GRC migration without carrying forward old risk?
• How can security teams reduce risk without redesigning legacy shared workflows?
• How should security teams govern ABAP customisation in large SAP environments without creating upgrade risk?
• How should security teams plan an SAP ECC to S/4HANA migration without disrupting business operations?