Integrated Risk Management
Through the application of technology and automation, we'll help you manage your risks efficiently and effectively across the entire enterprise.
Identity and Access Managaement
We'll help you ensure everybody within your organisation has access to the right systems and data, for the right reasons, and at the right time.
Cyber & Application Security
Our experts will uncover security weaknesses within your security design and business-critical applications. Helping you protect your organisation from both internal and external threats.
About us
A group of passionate individuals with a shared purpose to help the world's leading companies embrace best practices for GRC and risk management.
Partners
Turnkey's strategic partner network consists of selected organisations that complement our capabilities.
Corporate Social Responsibility
We are committed to being agents for change through our Climate Action Plan, championing diversity in our workplaces, and more.
Get in touch
We have operations in all corners of the globe, so see which office is nearest to you and connect with them.
Careers
We have operations in all corners of the globe, so see which office is nearest to you and connect with them.
Webinars & eBooks
All of Turnkey's webinars, guides and other insights available in one place.
Blogs
Read the latest insights from our experts on GRC and risk management, covering the latest industry topics.
Press Coverage
See all the publications where Turnkey, our experts and our successes have been noted.
Key events
See the key industry conferences on GRC, SAP security and risk management which we are attending.
Case Studies
Client satisfaction is of the utmost importance to us, and we strive to constantly deliver above expectations, going the extra mile at every opportunity.
FAQs
We've put together a comprehensive list of frequently asked questions - along with our responses - to the most common GRC and SAP security issues.
18 August 2014

Security Engagement

When should security get involved in a project?

The short answer to this is: as early in the project as possible!

One of the most challenging aspects of security for SAP projects is often seen when security teams are engaged late in the project lifecycle, when a project is already deep into the build phase of whatever development is taking place and the need to achieve functionality in a controlled, compliant manner is raised only after the requirements have been gathered. Often we see security as an afterthought to functionality and this presents a number of challenges for successful delivery.

These challenges  come about because there has been no opportunity for security to share in the design decisions, to understand the requirements from the point of view of an end-user, or to sit with process and risk owners to understand the control objectives of the organisation. 

Often, development teams proceed with creating new functionality, whether it be a portal application, a new transaction, program, or even a new report, they migrate it through a landscape and sometimes all the way to production before finding out that no-one can access their shiny new functionality. At this point, the security for the development is then handled as part of an incident management process, rather than being scoped as part of the project itself. This places pressure on security teams in terms of cost, time and results in a negative perception of the security function.

A lack of involvement from the security & authorisations function early in a project lifecycle means that important risk control objectives are often not incorporated in requirements and this can snowball and impact all phases of the project:

Design phase:

Without clear definition of the functional requirements of developments, the scope for security changes is not confirmed and it is extremely difficult to achieve a technical design which meets the requirements. Understanding the control objectives, risks which must be addressed and the technical architecture involved is essential. 

Without a clear set of requirements for both the business functionality and security, it can be particularly challenging to come up with a design for your roles which supports the needs of your organisation. In addition, security design is more effective when the needs of the business are understood by the security administrators. 

Build phase:

So, you have little or no functional / technical design documents on which to base your build of the authorisation components, but still a requirement to have roles in place to support the project. Without knowing what authorisations to grant, or restrict, the roles themselves may have insufficient authorisation (which will impact testing experience), or excessive authorisations, which will be highlighted by auditors. 

Testing:

Say you have managed, by virtue of a lot of effort in your build phase, to get roles built, the roles are handed over to UAT execution and at this point, the testers identify defects in the roles. Perhaps they permit access to some sensitive data or fail in the testing of some critical activity. These issues are then raised as defects in the role, rather than changes to the scope of the roles. Without a design, how do you know that the build fits that design?

Go-live:

If the testing phase of the project is signed off, despite (IN SPITE OF LINGERING) some lingering issues with the security, you now have to handle issues in the production system. Forcing changes through a business as usual process, you’ve got to deal with a negative perception of security, face time pressures on getting functionality working in production or may face the prospect of failed audits. At this point, your management now have to decide if they’re going to create a remediation project purely for the authorisations. This is one common justification for the creation of GRC projects, to identify issues and remediate.

How do you get early engagement?

It’s not an easy thing to change the way an organisation engages with the security teams, but one thing which I have seen work well lies in educating project and change managers about their responsibilities to include security in all phases of the project. An element of this can include stage gate approvals from security to exit each phase of the project. Using your existing change control processes, it should be possible to include a review step in the design phase and as part of stakeholder engagement to ensure that changes cannot progress until the security impacts have been assessed.

To summarise, if security is involved in sap projects from the outset, not only will it be more likely to work, the organisation will also save time and resources it would have deployed later in the process to fix the problems.

If you have any comments or questions, please feel free to use the comment submission below.