2015-08-26

seminars: continuity meets multi-sourcing

Continuity Planning is about armouring your business with an element of robustness.

Multi-sourcing is a delivery model where you orchestrate a strong business with multiple sourcing partners.

What happens when the issue of continuity meets multi-sourcing? In September, I will be co-hosting seminars (in Swedish) on this very topic. How can we protect our customers and our business by ensuring availability in the face of unexpected events, even when we are dependent on external partners? Come join us!

2015-08-24

know your dependencies

What might impact the continuity in your context? One key factor is dependencies.

Think of it. Are there deliveries, services, resources that you assume will always be available? Could you run your business without that special service provider, without those key individuals, those office premises, that technical infrastructure? If not, you must treat them accordingly.

Any business will have its dependencies. Knowing your dependencies and managing them proactively is a cornerstone for continuity.

2015-08-03

the continuity of what?

Before addressing continuity, ask yourself this question. What system (service, process, component) is in focus?

Sounds simple but if you stumble here, you won't get far. What is your scope and why does it need to have its continuity protected? Is it within your area of responsibility, do you have the mandate? Does its operational quality matter to your stakeholders? Who will foot the bill?

Stating where your context begins and ends is a great start and sends a signal to others to do their part.

2015-07-15

what is continuity to you?

According to Wiktionary, continuity means lack of interruption or disconnection; the quality of being continuous in space or time.

Think of it. Lack of interruption in a real-world context means being able to withstand interference, continuing [sic!] to function in the face of external events. What kind of events? Some will be anticipated and we can design our system (process? service?) for them. Some will be unforeseen. How can we design for the unexpected? We know we have to.

What is continuity to you?

2015-06-12

again, known unknowns and unknown unknowns

This week's #sthlmcrimsymposium was fun and valuable. This being my 2nd time, I had managed expectations better.

Sure, linking outdoor violence to substance abuse is different from preventing compromise of valuable information. But there are also similarities. There was a poster session about Situational Prevention in the context of incident response. Infosec has so much to learn from mature fields, such as Criminology.

Managing known unknowns. Constructing unknown unknowns. We're all in that business.

2015-06-01

on the unsinkable and the unthinkable

It started as a jolt on the lower deck

Swedish song-writer Mikael Wiehe captures bewilderment, affection, anxiety, hope, pride and despair during the final hours of the RMS Titanic. 103 years later on, this spectacular disaster offers lessons for those of us working with risk and security. Using the power of analogies, we can help our stakeholders approach difficult subjects in persuasive ways. While doing the best we can to protect our systems, we must admit that they are by no means unsinkable.

2015-05-13

vertical challenges

Riskkollegiet and Swedish Radiation Safety Authority (SSM) hosted a seminar on Risk Communication.

Informing is not communicating. Still, the prevailing perspective was that of authorities with their experts informing the public, motivating them to change behaviour.

I advocate local ownership of risk. We are the experts on our system, we own and manage its risk. But I must admit that there's a difference between horizontal communication within an enterprise and the challenges for government officials.

2015-05-11

continuity through imagination

What does it mean to be planning for the unexpected? Something out of the blue which we failed to foresee, how could we be planning around this?

Firstly, the unexpected might not be unheard of. We don't expect all engines of a jet plane to fail at the same time, but we know this has happened.

Secondly, let's differentiate between cause and effect. Our office might suffer a power outage. We can think of possible causes for this effect, but we won't know them all. Still, if we can imagine the effect we can plan around it.

2015-04-20

old rules for new stuff

Why do we need system-specific security requirements? Can't we just comply with instructions? Yes we can, and we must. But it's not enough.

A new system does new stuff (or familiar stuff in new ways) or we wouldn't bother constructing it. New stuff means new risk components (assets, threat sources, vulnerabilities) and consequently new risk. New risk means we cannot simply rely on old rules. We need to rethink how security is implemented for this very system. System-specific security requirements.

2015-03-30

from policy to real change

When you want something to happen, you can write a policy. Then what? Is it realistic or does the policy assume components which are not in place? Is it easy to adhere or will compliance be an uphill battle? Now that it's easy, have you anchored the policy, ensuring that stakeholders understand it? Also - are people motivated to adhere? Always remember: awareness is not motivation.

Once again:

  • define "right"
  • make it possible to comply
  • make it easy
  • communicate your policy
  • help people understand
  • build motivation
20150731