Tuesday, April 25, 2017

SDLC - Business versus IT streams

A model I created a long time ago.
 
 
 
Business responsibility
Technology responsibility
 
 























Investigation phase
·         Proposal business improvement opportunities.doc
o    Proposal for initiating a project and use of resource to improve the business; initial business benefit indication; very high level cost/benefit analysis; indication on how to continue with respect to resources, involvement of people, etc.
·         Business strategy planning.doc
·         Business change management plan.doc
 
 
[Management decision to continue]
·         Business resource planning for next phase
·         Priority definition
·         Assignment of business project manager
[Technology planning]
·         Technology resource planning
·         Priority definition
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 

















 
Analysis phase
·         Business process analysis.doc
o    business process diagram’s; data flow diagrams; includes automated and non automated aspects; IT opportunities; includes as-is and to-be versions; includes interactions with automated systems
·         Vision (scope statement).doc
·         Business case.doc,
o    containing brief outline of following items: business benefit; cost/benefit analysis – business & technical / operational & project; resource requirements – business & technical x internal x external; high level indication of timelines and milestones; change management analysis
ICT Strategy planning
·         IT Strategy Analysis & Definition .doc
·         IT Enterprise architecture analysis & defintion.doc
 
[Management decision to continue]
·         Budget provisioning
·         Resource planning
 
[Management decision to continue]
·         Budget provisioning
·         Assignment of technology project manager
·         Resource planning



 









 
Business project management
·         Project plan.doc
·         Business requirements document (detailed).doc
·         Scope management plan.doc
·         Staffing management plan.doc
·         Communication management plan.doc
·         Project schedule.mpp
·         Risk management plan.doc
·         Quality management plan.doc
 
Business design and change
·         Re-organisation blue print.doc
Investigation phase
·         Exploration of technical options.doc
o    potential technical solutions; high level cost benefit analysis, including project ROI and operational ROI; optional vendor quotes; technical & functional & data visualisation in schemas and text, taking technology enterprise architecture into account
 









 
 















 
Business project management
·         Project status report.doc
·         Project status dashboard.doc
·         Meeting minutes, issue logs, etc.
·         Project change log.doc
 
Business implementation
·         User acceptance test script.doc
·         Training manual.doc
ICT project management
·         Project plan.doc
·         Scope management plan.doc
·         Staffing management plan.doc
·         Communication management plan.doc
·         Project schedule.mpp
·         Risk management plan.doc
·         Quality management plan.doc
 
System analysis & design
·         Business requirements (system requirements).doc
·         Information analysis.doc
·         Functional design.doc
·         Technical solution design (system architecture).doc
·         COTS evaluation.doc











 
ICT Project management
·         Project status report.doc
·         Project status dashboard.doc
·         Meeting minutes, issue logs, etc.
·         Change requests.doc
·         Project change log.doc
·         UAT sign-off.doc
 
System development
·         User acceptance test script.doc
·         User manual.doc
·         Technology operation manual.doc2







 
 
 
[Management decision]
·         Sign off
[Management decision]
·         ICT operations acceptance
 
 
 
 
 

Thursday, February 23, 2017

Be careful with assigning more power to the CSO to improve information security

Information security has never been as important as now. It's being said and heard everywhere. But organisations should be cautious to translate this to more power for the CSO/CISO.

Information security is a complex matter and is all about risk management. Risks should be assessed daily throughout all levels of the organisations: business management, IT management, IT specialists and end-users. When a firewall expert makes decisions on how to configure a firewall, it is impossible for a Security Officer to participate. The same applies to when the business owner of an application specifies his requirements.

To make these security decisions, you take a variety of issues into consideration such as the perceived threat, the cost to mitigate, impact on usability or operational efficiency.

Information security is just one of the subjects that is being delegated down through the management hierarchy, just like for example financial responsibility.

The risk is that if a CSO and his team are assigned power, they will start telling the people in the organisation what they can and can’t do. And they will threaten staff with non-compliance and force them to follow rigid frameworks. Those others than might take a passive approach and will not take their responsibility and refer to the security department for taking actions. The relationship between Security Officers and the IT-team is in many organisations far from optimal. This has a negative impact on the actual security, even if you are compliant. Compliance does not mean that all is secure.

Specifically, because information security is so important, all employees and all managers should be made fully aware of their responsibility. They should be trained and should be guided with the process. Their effectiveness should be measured through personal KPI’s and team KPI’s. Audits will assist to measure the effectiveness of the organisation but audits and compliance should still be considered as a tool to assist with the objective of the organisation. And information security is only one of the objectives.

The Security Officers play of course a very important role. They can’t be made responsible for the security of the systems. Simply, because to achieve good security, actions should be taken spread out through the organisation that requires too much knowledge of too many technologies.

The Security Officers therefore should use the regulations and frameworks to guide the organisation through the processes, help them to check the status where they are at and provide recommendations for improvement. Of course, when they see a risk, they should not give in and still report the risk via an escalation path to management. But management then decides whether to accept the risk or to act.

If you need to improve your information security, I recommend to set stricter KPI’s for your managers and transform Security Officers into friendly but honest consultants.