What’s your organisation’s type when it comes to cyber security? Is everything justified by the business risks, or are you hoping for the best? Over the decades, I have found that no two businesses or organisations have taken the same approach to cybersecurity. This is neither a criticism nor a surprise. No two businesses are the same, so why would their approach to digital risk be? However, I have found that there are some trends or clusters. In this article, I’ve distilled those observations, my understanding of the forces that drive each approach, and some indicators that may help you recognise it. I have also suggested potential advantages and disadvantages. Ad Hoc Let’s start with the ad hoc approach, where the organisation does what it thinks needs to be done, but without any clear rationale to determine “How much is enough?” The Bucket of Sand Approach At the extreme end of the spectrum is the 'Bucket of Sand' option which is characterised by the belief that 'It will never happen to us'. Your organisation may feel that it is too small to be worth attacking or has nothing of any real value. However, if an organisation has nothing of value, one wonders what purpose it serves. At the very least, it is likely to have money. But it is rare now that an organisation will not hold data and information worth stealing. Whether this data is its own or belongs to a third party, it will be a target. I’ve also come across businesses that hold a rather more fatalistic perspective. Most of us are aware of the regular reports of nation-state attacks that are attempting to steal intellectual property, causing economic damage, or just simply stealing money. Recognising that you might face the full force of a cyber-capable foreign state is undoubtedly daunting and may encourage the view that 'We’re all doomed regardless'. If a cyber-capable nation-state is determined to have a go at you, the odds are not great, and countering it will require eye-watering investments in protection, detection and response. But the fact is that they are rare events, even if they receive disproportionate amounts of media coverage. The majority of threats that most organisations face are not national state actors. They are petty criminals, organised criminal bodies, opportunistic amateur hackers or other lower-level actors. And they will follow the path of least resistance. So, while you can’t eliminate the risk, you can reduce it by applying good security and making yourself a more challenging target than the competition. Following Best Practice Thankfully, these 'Bucket of Sand' adopters are less common than ten or fifteen years ago. Most in the Ad Hoc zone will do some things but without clear logic or rationale to justify why they are doing X rather than Y. They may follow the latest industry trends and implement a new shiny technology (because doing the business change bit is hard and unpopular). This type of organisation will frequently operate security on a feast or famine basis, deferring investments to next year when there is something more interesting to prioritise, because without business strategy guiding security it will be hard to justify. And 'next year' frequently remains next year on an ongoing basis. At the more advanced end of the Ad Hoc zone, you will find those organisations that choose a framework and aim to achieve a specific benchmark of Security Maturity. This approach ensures that capabilities are balanced and encourages progressive improvement. However, 'How much is enough?' remains unanswered; hence, the security budget will frequently struggle for airtime when budgets are challenged. It may also encourage a one-size-fits-all approach rather than prioritising the assets at greatest risk, which would cause the most significant damage if compromised. Regulatory-Led The Regulatory-Led organisation is the one I’ve come across most frequently. A market regulator, such as the FCA in the UK, may set regulations. Or the regulator may be market agnostic but have responsibility for a particular type of data, such as the Information Commissioner’s Office’s interest in personal data privacy. If regulatory compliance questions dominate most senior conversations about cyber security, the organisation is probably in this zone. Frequently, this issue of compliance is not a trivial challenge. Most regulations don’t tend to be detailed recipes to follow. Instead, they outline the broad expectations or the principles to be applied. There will frequently be a tapestry of regulations that need to be met rather than a single target to aim for. Businesses operating in multiple countries will likely have different regulations across those regions. Even within one country, there may be market-specific and data-specific regulations that both need to be applied. This tapestry is growing year after year as jurisdictions apply additional regulations to better protect their citizens and economies in the face of proliferating and intensifying threats. In the last year alone, EU countries have had to implement both the Digital Operational Resilience Act (DORA) and Network and Infrastructure Security Directive (NIS2) , which regulate financial services businesses and critical infrastructure providers respectively. Superficially, it appears sensible and straightforward, but in execution the complexities and limitations become clear. Some of the nuances include: Not Everything Is Regulated The absence of regulation doesn’t mean there is no risk. It just means that the powers that be are not overly concerned. Your business will still be exposed to risk, but the regulators or government may be untroubled by it. Regulations Move Slowly Cyber threats are constantly changing and evolving. As organisations improve their defences, the opposition changes their tactics and tools to ensure their attacks can continue to be effective. In response, organisations need to adjust and enhance their defences to stay ahead. Regulations do not respond at this pace. So, relying on regulatory compliance risks preparing to 'Fight the last war'. The Tapestry Becomes Increasingly Unwieldy It may initially appear simple. You review the limited regulations for a single region, take your direction, and apply controls that will make you compliant. Then, you expand into a new region. And later, one of your existing jurisdictions introduces an additional set of regulations that apply to you. Before you know it, you must first normalise and consolidate the requirements from a litany of different sets of rules, each with its own structure, before you can update your security/compliance strategy. Most Regulations Talk about Appropriateness As mentioned before, regulations rarely provide a recipe to follow. They talk about applying appropriate controls in a particular context. The business still needs to decide what is appropriate. And if there is a breach or a pre-emptive audit, the business will need to justify that decision. The most rational justification will be based on an asset’s sensitivity and the threats it is exposed to — ergo, a risk-based rather than a compliance-based argument. Opportunity-Led Many businesses don’t exist in heavily regulated industries but may wish to trade in markets or with customers with certain expectations about their suppliers’ security and resilience. These present barriers to entry, but if overcome, they also offer obstacles to competition. The expectations may be well defined for a specific customer, such as DEF STAN 05-138 , which details the standards that the UK Ministry of Defence expects its suppliers to meet according to a project’s risk profile. Sometimes, an entire market will set the entry rules. The UK Government has set Cyber Essentials as the minimum standard to be eligible to compete for government contracts. The US has published NIST 800-171 to detail what government suppliers must meet to process Controlled Unclassified Information (CUI). Businesses should conduct due diligence on their suppliers, particularly when they provide technology, interface with their systems or process their data. Regulations, such as NIS2, are increasingly demanding this level of Third Party Risk Management because of the number of breaches and compromises originating from the supply chain. Businesses may detail a certain level of certification that they consider adequate, such as ISO 27001 or a System & Organization Controls (SOC) report. By achieving one or more of these standards, new markets may open up to a business. Good security becomes a growth enabler. But just like with regulations, if the security strategy starts with one of these standards, it can rapidly become unwieldy as a patchwork quilt of different entry requirements builds up for other markets. Risk-Led The final zone is where actions are defined by the risk the business is exposed to. Being led by risk in this way should be natural and intuitive. Most of us might secure our garden shed with a simple padlock but would have several more secure locks on the doors to our house. We would probably also have locks on the windows and may add CCTV cameras and a burglar alarm if we were sufficiently concerned about the threats in our area. We may even install a secure safe inside the house if we have some particularly valuable possessions. These decisions and the application of defences are all informed by our understanding of the risks to which different groups of assets are exposed. The security decisions you make at home are relatively trivial compared to the complexity most businesses face with digital risk. Over the decades, technology infrastructures have grown, often becoming a sprawling landscape where the boundaries between one system and another are hard to determine. In the face of this complexity, many organisations talk about being risk-led but, in reality, operate in one of the other zones. There is no reason why an organisation can’t progressively transform from an Ad Hoc, Regulatory-Led or Opportunity-Led posture into a Risk-Led one. This transformation may need to include a strategy to enhance segmentation and reduce the sprawling landscape described above. Risk-Led also doesn’t mean applying decentralised, bespoke controls on a system-by-system basis. The risk may be assessed against the asset or a category of assets, but most organisations usually have a framework of standard controls and policies to apply or choose from. The test to tell whether an organisation genuinely operates in the Risk-Led zone is whether they have a well-defined Risk Appetite. This policy is more than just the one-liner stating that they have a very low appetite for risk. It should typically be broken down into different categories of risk or asset types; for instance, it might detail the different appetites for personal data risk compared to corporate intellectual property marked as 'In Strict Confidence'. Each category should clarify the tolerance, the circumstances under which risk will be accepted, and who is authorised to sign off. I’ve seen some exceptionally well-drafted risk appetite policies that provide clear direction. Once in place, any risk review can easily understand the boundaries within which they can operate and determine whether the controls for a particular context are adequate. I’ve also seen many that are so loose as to be unactionable or, on as many occasions, have not been able to find a risk appetite defined at all. In these situations, there is no clear way of determining 'How much security is enough'. Organisations operating in this zone will frequently still have to meet regulatory requirements and individual customer or market expectations. However, this regulatory or commercial risk assessment can take the existing strategy as the starting point and review the relevant controls for compliance. That may prompt an adjustment to security in certain places. But when challenged, you can defend your strategy because you can trace decisions back to the negative outcomes you are attempting to prevent — and this intent is in everyone’s common interest. Conclusions Which zone does your business occupy? It may exist in more than one — for instance, mainly aiming for a specific security maturity in the Ad Hoc zone but reinforced for a particular customer. But which is the dominant zone that drives plans and behaviour? And why is that? It may be the right place for today, but is it the best approach for the future? Apart from the 'Bucket of Sand' approach, each has pros and cons. I’ve sought to stay balanced in how I’ve described them. However, the most sustainable approach is one driven by business risk, with controls that mitigate those risks to a defined appetite. Regulatory compliance will probably constitute some of those risks, and when controls are reviewed against the regulatory requirements, there may be a need to reinforce them. Also, some customers may have specific standards to meet in a particular context. However, the starting point will be the security you believe the business needs and can justify before reviewing it through a regulatory or market lens. If you want to discuss how you can improve your security, reduce your digital risk, and face the future with confidence, get in touch with Tom Burton, Senior Partner - Cyber Security, using the below form.

Would you feel comfortable flying in an aeroplane designed by engineers who only considered what might go wrong after they had built it? ‘Secure by Design’ (SbD) is not a technology, it is a set of principles to be adopted to improve business risk and resilience. It has strong similarity to conventional engineering practices, and it will save money by reducing wasteful rework. The critical first step is to understand the risks that the solution will be exposed to. Like Failure Mode Analysis in conventional engineering, these inherent risks form an essential part of the solution requirements. The design can then be a collaborative and iterative exercise of review and enhancement to meet the security requirements. Effort spent defining requirements before design and implementation is widely recognised to save time and money. The situation is no different with security requirements, but there are wider benefits as well, compared to addressing security late in the lifecycle: Security controls applied after design and implementation are more likely to restrict functionality, undermining overall user satisfaction and the return on investment Early engagement reduces the risk of budgets overruns, or having to accept inadequate security if you can’t secure the budget A well-documented set of risks, security controls and design decisions can then follow the solution through implementation and into operations, enabling future change to understand past rationale Above all else, late identification of risk and security requirements causes wasteful rework of the solution, which will cost time and money The key to success is defining the system scope correctly. If the scope is too great and encompasses a number of separate systems, then the benefits are eroded and the exercise becomes more akin to a homogenous enterprise risk assessment. If the scope is too small, the number of systems becomes unwieldy and unsustainable to assess and manage. It is not a Technology, and it is not New Despite what you might believe from some of the cyber tech product sheets, SbD is not a technology (for that matter, Zero Trust, which we see as a valuable component of SbD practice, is not a technology either). It is a philosophy or strategy, a set of principles that bring efficiency, consistency, and discipline to cyber risk management. You may find tools that help you to adopt these principles, and the practice requires a sound understanding of technology, but above all SbD is a human endeavour. Like many other buzzwords in the security community, SbD is frequently presented as something rather mystical, requiring specialist knowledge and attracting a new set of standards and vocabulary. We don’t hold with this concept; in our view, it ‘does exactly what it says on the tin’. It is about ensuring the system’s very design enforces security and mitigates risk rather than relying on sticking plasters applied after implementation. Whether those design features are preventative controls, controls to detect and respond to issues, or any other category, they will have been defined and tuned to the specific risks and characteristics of the solution in advance (and managed through life). The concept is not new. The benefits of early security engagement have been known for some time. But sadly, this has been frequently ignored. As the cyber security industry matures, and the frequency and impact of cyber attacks on businesses increases, the call for this discipline has been increasing. Governments are starting to mandate it in the standards and security governance of technology programmes. The Similarities between Digital and Conventional Engineering Most engineering lifecycles, not just those related to digital solutions, recognise the importance of spending adequate time defining the requirements. At the start of the programme, the level of uncertainty will be at its greatest. The purpose of Requirements Engineering is to reduce that uncertainty so that design and implementation can proceed with direction and to minimise the number of ‘wrong turns’ that have to be unwound. If you do not reduce uncertainty as early as possible, the problems grow as they move downstream, and solving them then becomes a disheartening exercise in ‘pushing water uphill’. Let us imagine that we want someone to build us a house. We would go to our local house building company and commission the job; if they get started immediately, the chances of the end result being anything like what we originally wanted would be almost zero. Where do we want our home located? How many bedrooms, bathrooms, and living rooms? What architectural style? What about the fixtures and fittings? We will identify everything wrong once the sub-optimal, ill-thought-out building is completed for our inspection. Putting those right at this stage will cost orders of magnitude more than they would have with an effective design phase. Worse, there will be many issues that we cannot put right without starting again, and, therefore, we will be left operating in a flawed and compromised solution. Where do we Start? So, how do we identify the security requirements for the design? What is Requirements Engineering in a security context? The security requirements are defined by the risks that the solution will be exposed to. One of the most important SbD principles emphases this by stating that you must ‘adopt a risk-driven approach’. These risks and your organisation’s appetite to accept risk determine the requirements for controls; or, to put it another way, the controls are required to mitigate the risk to a level that it is within your organisation’s appetite. Again, there are similarities with conventional engineering. Understanding the risks that the design must treat is similar to identifying the Failure Modes of an aircraft or other system. The risks need to be articulated so that all stakeholders can understand them, including by the non-technical and non-security communities. Getting all stakeholders to sign off on these inherent risks is crucial to ensure that everyone recognises the constraints the solution will be confined by. If you do not have a sound understanding of the risks before work starts on the design, let alone the implementation, then you are lacking an essential part of the solution requirements. Review, Collaborate, and Iterate Once you have the security requirements, you can feed them into the design process similar to functional requirements. Selecting appropriate controls to meet the requirements will undoubtedly require some specialist expertise. However, this is similar to the requirement for technical architects to be familiar with the technologies employed in the solution stack. This design process should be iterative. Requirements change, frequently due to learning in one iteration providing feedback into the next. The security requirements may influence the architectural approach to fulfil the functional requirements. Occasionally, a complete rethink may be required to adjust the functional requirements to meet the security constraints while also meeting the business needs. However, like the house-building analogy above, this time spent optimising the design will be significantly less than the time, cost, and disruption caused if security is addressed later in the lifecycle. Each iteration takes the proposed design, reviews the inherent risks to identify any that can be retired or if new ones have been created, assesses the residual risk given the existing security controls, and identifies additional security controls to reduce the residual risk to an acceptable level. Done collaboratively, this can introduce fast feedback into the design process, and, over time, the technical architects will become more familiar with security issues and their resolutions. Zero Trust’s Role in the Exercise, and Scope Definition Zero Trust is another trending buzzword frequently camouflaged with mystique, or hijacked as a ‘feature’ on product sheets. My view on Zero Trust is similar to my view on SbD: it should be easy to understand, and ‘does exactly what it says on the tin’. In design and in operations, we start from the baseline that nothing is trusted. Whether it is digital identities, devices, applications, or services, we can only trust them once we have an objective and explicit reason to trust them. We use the principle of Zero Trust extensively when applying SbD. By having no implicit trust in any identity, device, or service, we can decide on the minimum level of trust we need to enforce and the maximum level of trust that the entity can offer. If the maximum trust on offer is less than the minimum trust we need, then there is a design decision to be made about how we close the gap. It may be necessary to reduce functionality in order to reduce the required minimum. Or, we may need to put in place other compensatory controls to reduce the risk in other ways. Defining an appropriate scope of the system is key to success. If you set the scope too large, then everything is inside the ‘circle of trust’, and SbD becomes a homogenous exercise in enterprise security. If you set the scope too small then you will drown under the sheer quantity of projects to manage. The World is not a Greenfield Site, and Security is not a Fire-and-Forget Weapon The world is not a greenfield site, and there will be challenges retrofitting a SbD approach to the broad portfolio of legacy solutions. There is no simple or quick solution to this, it will be a case of progressively revisiting each project’s architecture and identifying the changes that will make it secure by design. But, risk can help us here too. Some projects or services will be sufficiently low-risk so that they can be tolerated until they are retired (so long as they are not trusted by any other more important system). The SbD approach lends itself well to a progressive rollout. SbD will limit the negative impact that a legacy system can have on a target system, because nothing outside of a project’s scope is implicitly trusted. You can only aim for a perfect world by progressively taking steps to make it a better world. In this article, we explain why risk management needs to be addressed at the design phase of projects. This does not mean that we believe this is the end of the journey. Security and risk management still needs to be managed in operations as new threats change the risk profile, or change is applied to a system. But with the foundations laid early in the lifecycle, the task of management through life becomes easier. The documentation generated by SbD should provide clear traceability between risks and controls. When a project is reviewed in life, the rationale behind previous decisions can be clearly understood, enabling change to be an informed process. Summary This article outlines why I believe applying the principles of Secure by Design avoids issues getting into operations, and saves time and money. If what I have described already seems obvious, then that is positive. However, from my experience, too many projects do not consider security to be an essential component of design. I believe that this is a missed opportunity, and, when applied correctly, it delivers solutions that are more secure and easier to manage.

What are NIS2 & DORA? Standing for the Network and Information Security Directive, the NIS Directive is an EU Regulation which details a blanket level of cyber security measures required of all Member States and organisations within them, as well as those with or seeking to establish a footprint in Europe. In 2022, the Official Journal of the European Union published their updates to this Directive in NIS2 , which made their regulations more stringent while broadening the scope of who it applies to. One of these amendments differentiated between entities deemed ‘important’ and ‘essential’, whereby the latter, which includes Banking and Finance, will be subject to closer scrutiny and greater penalties regarding their compliance with NIS2 – or lack thereof . This level of regulated scrutiny will also be heightened by a further EU directive, the Digital Operations Resilience Act ( DORA ). Similar to NIS2, DORA is described as establishing a ‘ comprehensive framework for harmonising digital resilience processes and standards ’. However, where NIS2 applies to all business entities within the EU, DORA is specifically designed to ‘strengthen the resilience of digital operations in the financial sector ’. Thus, though accounting for similar processes and practices, as we shall outline, the emergence of both NIS2 and DORA represent at least two sets of cyber criteria which financial entities must comply with, not only to avoid legal penalty, but to remain robust in an increasingly dangerous digital environment. NIS2 and DORA are scheduled to become national law on the 17 th October 2024 and 17 th January 2025 respectively, and it is important to understand both in order to ensure that your business is compliant with their requirements. NIS2 Requirements Chapter 4 of NIS2 requires that all Member States of the EU ensure that all of their essential and important entities ‘take appropriate and proportionate technical, operational, and organisational measures to manage the risks posed to the security of network and information systems’ . By ‘appropriate and proportionate’, NIS2 directs all such entities to adopt an ‘all-hazards approach’, by which they refer to a baseline set of requirements including: a. Internal Security Policies: Develop and enforce good essential policies that ensure robust internal security practices. b. Incident Handling: Establish tested protocols to effectively respond to and manage security incidents. c. Backup Management & Disaster Recovery: Ensure reliable backup solutions and disaster recovery plans to safeguard data integrity, also ensuring continuity. d. Supply Chain Security: Maintain mutual responsibilities with partners through clear connections and dependencies to avoid the cascade effect of major incidents. e. Information Security Maintenance: Ensure the security of your network, including vulnerability handling and disclosure. f. Ongoing Assessment: Continuously update and monitor information security measures to protect against the ever-changing street smarts of evolving threat actors. g. Cyber Security Hygiene & Training: Regularly assess and adapt security measures to current threat landscapes, which are often basic and repeated. h. Cryptography & Encryption: Provide continuous cyber security training promoting best practices among employees, and ensuring Quantum-ready cryptography, a subject of other evolving regulations. i. Human Resources Security: Implement thorough background checks and enforce security protocols for all personnel. j. Multi-Factor Authentication: Enhance access control through the use of multi-factor authentication, which is always a feature of successful cyber incidents. DORA Requirements DORA is considered a Lex Specialis for financial sector entities, meaning that, where it possesses overlapping or shared regulations and principles with NIS2, DORA takes precedence. Thus, though it is still important to remain aware and informed regarding NIS2 and its requirements, it is more important to be equipped with an acute understanding of DORA. DORA requires that all financial entities be equipped with an ‘ internal governance and control framework ’ designed to strengthen their cyber defences, particularly in regards to the transfer of data, risk of corruption, confidentiality and loss of data, and protection from human error. In order to ensure this, DORA insists upon the implementation of the following processes: a. An information security policy with clearly defined rules to protect the availability, authenticity, integrity, and confidentiality of data. b. A sound infrastructure management structure which makes use of appropriate techniques and mechanisms, such as those which isolate affected assets in the event of a cyber attack. c. Policies which limit the physical access to information assets and ICT assets to what is legitimate and approved. d. Protocols for strong authentication mechanisms based on relevant standards and systems, including the use of encryption. e. Controls for ICT change management in order to ensure that any changes are recorded, tested, assessed, approved, and verified. f. Appropriate policies for patches and updates . Implications for the Finance Sector Both NIS2 and DORA may appear to establish relatively basic levels of cyber security awareness and defence, however it is important that they are properly implemented and strengthened within your operations. This is partly due to the financial and reputational losses that can and will impact your organisation in the event of a cyber security breach. In considering financial entities to be essential, NIS2 makes them liable to a fine of up to €10m or 2% of their annual turnover, whichever is higher. Similarly, DORA penalises any instance of non-compliance with a daily fine of up to 1% of the average daily worldwide turnover of the financial entity until compliance is reimposed. Furthermore, the reporting obligations of both Acts pose significant and specific considerations to financial entities, based on how and when an organisation should bring awareness to a potential or recent cyber security breach. DORA’s Article 10: Detection imposes that financial entities shall ‘have in place mechanisms to promptly detect anomalous activities’, and expands the reporting process in Article 17: ICT-related incident management process to ensure that ‘major’ cyber security incidents are reported to the appropriate management bodies in order to enact mitigation and prevention procedures. Similarly, NIS2’s Article 23: Reporting Obligations requires that all essential and important entities promptly identify and report any ‘significant’ cyber security breach or incident to their representative computer security incident response teams (CSIRTs). There are two main indicators which make an incident ‘significant’ under NIS2: one is that it has affected or caused damage to other entities or persons; the second is that ‘it has caused or is capable of causing severe […] financial loss for the entity concerned’. This is particularly emphatic for organisations which by nature and definition handle and advertise the possession of large amounts of money, a consideration which DORA highlights as an Act specific to the financial sector. In their classifications of ICT-related incidents which financial entities should use to determine their impact, DORA specifies ‘the criticality of services affects, including the financial entity’s transactions’ as well as ‘the economic impact, in particular direct and indirect costs and losses’. Thus, it is crucial for financial organisations to ensure that their operations are properly barricaded against cyber threats, and that they have airtight contingencies and reporting protocols in place in case they are breached. Finally, it is important to internalise clear accountability within your organisation. NIS2 makes it clear that the responsibility for the approval, delivery, and maintenance of an essential entity’s cyber security risk-management measure rests with the management bodies of the entity. This includes coordinating cyber security training and the provision of ‘sufficient knowledge and skills to enable them to identify risks and assess cybersecurity risk-management practices’. DORA is even clearer in this regard, specifying that the management body of the financial entity shall ‘bear the ultimate responsibility for managing the financial entity’s ICT risk’. Thus, the stakes are higher for executives and C-suite professionals to ensure compliance, as they will be the ones held accountable for breaches and attacks. How Cambridge MC can Help Whether your company is based primarily inside or outside the EU, it is crucial that your organisation complies with NIS2 and DORA by the end of the year if you have any entities or subsidiaries, or currently/plan to conduct work in any EU Member States. In any case, NIS2 and DORA represent aspirational sets of guidelines pertaining to the cyber hygiene of your organisation that would only strengthen it to internalise.  This is particularly salient in a regulatory culture which is increasingly prioritising and scrutinising cyber security. As of April this year, the UK Government implemented minimum security standards to protect consumers and businesses from cyber attacks. These include the banning of easily guessable default passwords; regulations which, like NIS2 and DORA, are seemingly basic yet possess higher stakes for non-compliance. At Cambridge Management Consulting, we have a team of experienced Cyber Security professionals with decades of combined practical experience in the field, as well as detailed and up-to-date knowledge on all relevant regulations and principles. To avoid your organisation from being left behind or penalised for a lack of cyber maturity, contact our cyber team to understand your pain points and vulnerabilities—we will work with you to construct, assess, and deliver a comprehensive strategy to resolve them. Contact John Madelin , our Managing Partner for Cyber Security, or learn more about our Cyber Security capability here .

Implementing continuous development to address new opportunities and requirements The client owned a mature, large-scale web application that housed vast amounts of sensitive information. One part of this application was accessible from the internet, while the other was used within government infrastructure, which had a low tolerance for risk. Due to its business-critical nature, the client sought the expertise of Tom Burton, a Cyber Security specialist at Cambridge Management Consulting, to update the application to meet new opportunities and modern network requirements. The Challenge The client needed to integrate a new third-party SaaS web service into the existing application to enhance business efficiency and process speed. This SaaS environment was subject to compliance with some UK Government security standards, however they could not apply conventional, direct assurance and accreditation activities because of the third-party's SaaS shared delivery model. The client needed the final solution to recognise this uncertainty while managing risk, security, and business benefits. The Approach To resolve their challenges, Tom and his team adopted an approach based on the principles of 'Secure by Design', working with the client's business and engineering representatives to jointly develop the optimum integration approach and security controls before implementations started. The lack of assurance meant that the integration needed to treat 3rd party SaaS as largely untrusted. The client had several architectural options, each with different implications in their cost, timescale, risk profile, business efficiency, and future flexibility. Tom iterated the design with the client, helping them to select the best, most viable solution, reconsidering risk, compensatory controls, and benefits at each stage. Adopting a risk-driven approach, Tom identified the inherent risks that the change would introduce regardless of the integration approach as a first critical step. These risks were understandable to the non-security and non-technical communities. Getting stakeholder agreement on them ensured that all parties would recognise the constraints the solution would have to live within. The client proposed their preferred solution architecture, enabling Tom to assess the residual risk that the change would present, and propose additional security controls to bring that risk down to an acceptable level. As Tom's work progressed, the client adjusted the solution architecture in response to address options that became unviable or inefficient. Alternative options and their implications were discussed. When changes had been decided, Tom quickly reviewed and updated the risks and security controls, introducing fast feedback into the design process, and ensuring that his architecture design was built with future flexibility internalised. The inherent risks did not remain static either, and were reviewed on each iteration, adding new risks that arose, and retiring redundant ones according to the proposed solutions characteristics. Outcomes & Results 1. Faster, Cheaper Deployment If security had been considered late in the change process after implementation, it is likely that the solution design would have needed significant rework, retrofitted inefficient controls with a negative cost and operational impact, and/or a higher level of risk accepted. Tom and his team avoided these costly and unnecessary effects by getting early agreement on the risks that needed to be treated, and quickly iterating to an optimal solution with the client. 2. Long Lasting Solutions This approach also aligned with the principles of embedding continuous assurance and making changes securely because all controls can be tied back to the risks that they are addressing; future changes will be able to refer to these dependencies and build on them rather than undermine the existing security. 3. Positive Reception The Government end-client was delighted with the thoroughness of the analysis and documentation, had no concerns about the risk or mitigations proposed, and saw significant benefits in the collaborative approach that had been adopted.