Practical Guide to Delivering Enterprise Security Capabilities

The following information may seem obvious but the experience will tell you that even the most straight forward, cheap, logical and reasonable risk-reducing solutions can be tied up in red tape for months or years if there is no collective ‘will’ to push the change through.

The points raised below are mostly applicable for large corporations and large government departments (as that is my recent experience) although they may also be applicable in the small, medium enterprise space (SME) dependent on internal change culture. Though I will caveat that I am confident small companies can also create self-defeating, contradicting policy and process just as well as large companies.

The main points you will need to consider for successful information security change delivery is… (not exhaustive)


Practical Guide to Delivering Enterprise Security Capabilities

Business Case

Senior management, budget holders ‘buy-in’ and financial resources to support successful delivery must be planned, documented and approved. The capabilities outlined in the business case must be aligned to the strategic documentation. Project delivery resource estimates and project team outline ROM costs should also be included and realistic.


Project delivery team and [1]Solution Partner

Project Manager – Keeping a schedule, project planning, unblocking issues, production and presentation of management information, working with the team to ensure tasks are delivered on time.

Security Solution Architect (pref. familiar with the solution) – Solutions focussed Security Architect is ideal as they can do two jobs. 1) design solution and 2) prepare security architecture (whilst ensuring the hands-on engineers are sticking to script).

Business Analyst/ Business Change – Communications focussed Business Analyst is ideal, for programmes that require cultural change, business process change, major changes in working practices this is a critical role. Where this is less important the Business Analyst can wear this hat too.

Solution Technical Engineer SME – Hands on keyboard engineer with skills in the specific solution (preferably). Engagement of temporary SME to install configure, coach and support the future operating team as part of the project delivery works really well. If you don’t have or can’t onboard someone who already has the expertise in a specific technology one of your existing engineers can be trained and coached, but this will cause project delay which will need to be factored in.

An engaged supportive solution partner – The provider of the COTS[2] product or development teams must be supporting your delivery team (pref. as part of the contractual agreement). Professional days are a good thing but will be expensive so need to be used efficiently. It is very important to choose vendors who will support your journey to full coverage.

(the above roles could be merged; members of the team fulfilling more than one role as long as project time, skills and resources permit)


Commercial Off the Shelf Security Capabilities (COTS)

New security COTS capabilities are released all the time. Companies and Governments are finding these COTS products preferable to developing their own capabilities and all the work and expertise required to do that.

These security COTS products are being used to create a security wrapper around business applications and cloud environments. This is especially relevant in the digital transformation as organisations look to secure their data in the cloud.

So it couldn’t be more straightforward, just buy and piece of software because the company seem to know what they are talking about, have the IT teams install it into the enterprise, job is done.

This approach is fraught with danger, as installing anything into the enterprise is a project, and installing any large solution with integrations is a programme of work. These off the shelf solutions, need to be contextualised and have use case constraints (these solutions are rarely as simple as ‘click and done’)

[1] If the provider of your software is not behaving like a delivery partner then any use cases that are outside of standard functionality are almost undeliverable.
[2] COTS doesn’t always mean no development. Some solutions will need significant customisation or development to meet use cases/requirements, especially open source off the shelf products. This risk should be included in the RAID and be called out in the solution selection matrices with the mitigation of more specialist SMEs.


Project Delivery Process

Document a process that the project will use to deliver the capability. Feed-in all external requirements, use cases and stories; user, procurement, project governance (designs), information risk, accessibility and security (yes that’s right, security requirements for security solutions).

There will be requirements for the project to follow (Governance and Process) High-level requirements of the capability (functional requirements) and requirements of the total end solution (Non-Functional requirements). These should be traceable, a SABSA attributes table can make this easier. (Unless the enterprise has a stipulated architectural framework requiring other traceability methods such as ‘DOORS’).

Take components from best practice, business-specific and agile methods to create a route to delivery that meets all stakeholder needs and governance processes then write document how the project will move forward. Don’t short cut on key project documentation; RACI, Business Case, Solution Selection Matrices, Architectural documents. The content of these documents will get reused throughout the project (for example when presenting the information security governance boards).

If there is one lesson to be taken from my experience it is;


 “More Haste less speed”


Set achievable timelines after discovery work is complete. If the capability is audit driven the deadlines are usually arbitrary and can be project defined. (so why give yourself an unachievable goal). If the delivery of the strategic solution isn’t acceptable to investigate a tactical solution (preferably using pre-requisites for the strategic)

Groundwork and discovery are key activities. If you skip/miss required steps or provide bare minimum information especially in the early stages (because either you are keen to show progress or you are being pushed) sooner or later an issue will be raised, the project team will unravel and everything will stop.

This will cause extra use of project resources, delivery delays, time and effort to rebuild relationships with governance teams, not to mention it will adversely affect the all-important project team credibility rating.

If you must start now because you are being pushed, enter as a project risk (RAID or Risk Register) that you might miss something in the discovery stage causing delays later.



Iterative capability delivery starting with a Minimum Viable Product (MVP) release is easiest to achieve but you will need to ensure that the MVP release meets the most important of the business requirements/objectives. If it does not, the project will be an easy target for any upcoming project reassessment initiatives.

MVP must meet the most important of the business objectives, this should be documented in the solution design. For an information security change project, this must be aligned to risk (information security organisation business requirements being derived from risk).

To ensure that it is demonstrated that business objectives are met two high-level designs should be produced (IMHO). A capability design that is non-solution specific and a solution design that is software solution specific. This way all business objectives, use cases, functional and non-functional requirements can be traced to solutions. The capability design (Conceptual Architecture) is to be enduring and revisited periodically to ensure currency or when selected solutions are re-evaluated for effectiveness. It can also be used to select new solutions as they become available or when agreements end or if a conflict arises.

The solution design will address solution specific issues (Logical Design), where the product will be hosted, how it will connect to other components, what the platforms are, how the product is deployed, managed and maintained etc.


Implementation teams will need support during installation in non-production and production environments. Use the relationships and time that you have with the solution partners to best effect and produce a future operating model proposal, training plans, secure configuration/build documentation, onboarding process and route to live. This can then be used to capture and address end-user questions and concerns as you progress through the design and delivery process.



The dreaded governance boards. Do not try to short cut or circumvent governance processes, do not try to circumvent or downplay information security risks that the new capability introduces. Work with the risk and governance teams to provide workable solutions and compromise design decisions where you can. Even if it seems counter-intuitive.

During the journey, you will come across security and integration issues that are enterprise-wide; policy or technical constraint-based. They will affect your project. Escalate those, register risks or apply for a waiver (worst case) if that is the way the enterprise requires them to be dealt with. Write them out of your solution to get through governance.

Do not try to fix all the existing enterprise-level issues you come across, otherwise, your project will drift to the right and soon the issues will become principles to be debated and debated to the detriment of your project delivery. There will always be issues outside of your immediate control (and scope). Find a way to manage/escalate issues as they appear to you. Again, document your treatment of these as a process, then move on.

Most security governance boards will want to see why you have selected a specific product, so create a solution selection matrix with the key business objectives and outcomes.

Sometimes you will be delivering a product that has already been selected, even if that has happened fill in a quick product selection matrix with the details that you do know. This will make governance easier.

Learning to deal with an infuriating level of pedantry is the solutions security architects bread and butter. Document left field clarifications and requests, research them then go back with the answers. If you still hit a wall, ask the governance teams for support.



 A much-overlooked requirement of any change project is real communication. Good communication is best achieved by using a communications plan. Document all the ceremonies, update meetings, project boards, steering groups, working groups, update bulletins, etc. Write down who needs to know what and when.

Send this plan to all stakeholders according to your RACI and have it approved. This will be a living document and as soon as you discover a gap add it.

As a solutions architect, how many times have you heard “no one told me about that” as you are introducing the solution. This can be disastrous to a project and must be planned for. Under-resourced communication is a project risk and should be registered as such.


Management Information

To enable the programme/project sponsor to have visibility to progress management information will be required. The best way to do this is to employ project management tooling that will track tasks such as JIRA (or similar tools). A set of reports and portal can be configured to allow stakeholders to see what is happening with the project. This information can also be used for steering/programme board information. Automate these report as much as possible to leave the team free to deliver the project.

Create and agree on project metrics with all stakeholders to enable progress to be measured quickly and easily. These can be quoted in communications.


Project Framework

During the delivery process, lessons will be learned with regards what working and what isn’t working that can be priceless for future projects and should be captured and fed back into the delivery process. Use whichever ceremonies are current in the organisation to do this, if they don’t exist create them and add them to your delivery framework for communication.

Create a delivery framework for your team or organisation’s re-use. Once you have successfully delivered a project into an organisation. Tweak it with the lessons learned and reuse it next time or communicate it to a wider audience.

The above is not exhaustive by any stretch, but good food for thought to anyone venturing into this delivery space.


Experienced Delivery Team

Pionen has a very experienced security solutions strategy and delivery team and would be happy to help your company or department successfully deliver security change projects and programmes as we have been doing for other large government and financial institutions.

If you would like to hear more, please contact or email for an informal chat.

Posted by : Kelly Price | On : May 18, 2020