What Is the Ruling?

The new SEC ruling requires disclosure following an incident at a publicly traded company. This should come as no surprise to any organization already dealing with data protection legislation, such as the GDPR in Europe or California’s CCPA. The final rule has two requirements for public companies:

• Disclosure of material cybersecurity incidents within four business days after the company determines the incident is material.
• Disclosure annually of information about the company’s cybersecurity risk management, strategy, and governance.

The first requirement is similar to what GDPR enforces, that breaches must be reported within a set time (72 hours for GDPR, 96 for SEC). To do this, you need to know when the breach happened, what was contained in the breach, who it impacted, and so on. And keep in mind that the 96 hours begins not when a breach is first discovered, but when it is determined to be material.

The second part of the SEC ruling relates to annual reporting of what risks a company has and how they are being addressed. This doesn’t create impossible hurdles—for example, it’s not a requirement to have a security expert on the board. However, it does confirm a level of expectation: companies need to be able to show how expertise has come into play and is acted on at board level.

What are Material Cybersecurity Incidents?

Given the reference to “material” incidents, the SEC ruling includes a discussion of what materiality means: simply put, if your business feels it’s important enough to take action on, then it’s important enough to disclose. This does beg the question of how the ruling might be gamed, but we don’t advise ignoring a breach just to avoid potential disclosure.

In terms of applicable security topics to help companies implement a solution to handle the ruling, this aligns with our research on proactive detection and response (XDR and NDR), as well as event collation and insights (SIEM) and automated response (SOAR). SIEM vendors, I reckon, would need very little effort to deliver on this, as they already focus on compliance with many standards. SIEM also links to operational areas, such as incident management.

What Needs to be Disclosed in the Annual Reporting?

The ruling doesn’t constrain how security is done, but it does need the mechanisms used to be reported. The final rule focuses on disclosing management’s role in assessing and managing material risks from cybersecurity threats, for example.

In research terms, this relates to topics such as data security posture management (DSPM), as well as other posture management areas. It also touches on governance, compliance, and risk management, which is hardly surprising. Yes, indeed, it would be beneficial to all if overlaps were reduced between top-down governance approaches and middle-out security tooling.

What Are the Real-World Impacts?

Overall, the SEC ruling looks to balance security feasibility with action—the goal is to reduce risk any which way, and if tools can replace skills (or vice versa), the SEC will not mind. While the ruling overlaps with GDPR in terms of requirements, it is aimed at different audiences. The SEC ruling’s aim is to enable a consistent view for investors, likely so they can feed into their own investment risk planning. It therefore feels less bureaucratic than GDPR and potentially easier to follow and enforce.

Not that public organizations have any choice, in either case. Given how hard the SEC came down following the SolarWinds attack, these aren’t regulations any CISO will want to ignore.

The post Navigating the SEC Cybersecurity Ruling appeared first on Gigaom.

The post The Good, The Bad, & The Techy: Insider Risk Management appeared first on Gigaom.

The post The Good, The Bad, & The Techy: Is There Life After Incidents? appeared first on Gigaom.

The post The Good, The Bad, & The Techy: Workplace Transformation appeared first on Gigaom.

The post The Good, The Bad, & The Techy: The (Not So) Hidden Costs of AI with Noble Ackerson appeared first on Gigaom.

The post The Good, the Bad, & The Techy: Edge Kubernetes with Said Ouissal appeared first on Gigaom.

The post The Good, The Bad, & The Techy: All Things 5G with Karl Connolly appeared first on Gigaom.

Transformations that Haven’t Delivered

The cloud is the most obvious example. The idea you could replace all your systems and infrastructure with brand new stuff that’s easier to use, deploy, and scale—at a lower cost—has been hugely compelling. Unfortunately, the principles may be true, but then there’s the Jevons paradox: simply put, the more you have of something, the more you use it, so instead of costs lowering over time, as you might expect with increased efficiency, they increase with greater use.

As a result, boring finance types have been turning the screws on cloud spend. Moreover, at the end of 2022, interest rates started going up and money started to cost money, moving cost optimization from a “nice-to-have” to a need. Accountants are winning and innovators can’t just do whatever they like, hiding behind the banner of “digital transformation.”

If the momentum behind cloud-for-cloud’s-sake marketing is waning, it’s no surprise we’re turning our attention to the next bit of technological magic—artificial intelligence (AI)—or more accurately, large language models (LLMs). And this new manifestation has attributes similar to cloud: apparent low cost of entry, transformational potential for business, and so on.

But even as it begins its transformations, it is already signaling its doom, not least because LLMs are about processing rather than infrastructure. They create new workloads with new costs, rather than shifting a workload from one place to another. It’s a new line on the budget, a separate initiative with no real efficiency argument to sell it.

“But it has the power to transform!” cry the heralds. Sounds good, but for the last wave of digital transformation delivering, to put it kindly, sub-optimally. We’re three to four years into many initiatives, and the rubber has been hitting the road, in some cases, with much wailing and gnashing of teeth.

The Challenge with Digital Transformation

According to a recent PWC survey, “82% of CIOs say achieving value from adopting new technologies is a challenge to transforming.” Read between the lines and that says, “We’re not sure we’re getting what we thought out of our initiatives.” Meanwhile, consider the 100 million pounds spent by the UK city of Birmingham on Oracle-based solutions, a significant factor in the city declaring bankruptcy.

For every public example of a large technology project failure, tens more go undeclared. A technology vendor told me that it was common to hear of a business investing millions into a platform, only to quietly write it off a couple of years later. As another example, an end-user organization told me it adopted a scorched earth policy to move its infrastructure to the cloud, before rolling it back in pieces when they found they couldn’t lift and shift the entire application architecture with its manifold vagaries.

I get why people buy into the dream of massive change with epic results. I mean, I love the idea. Earlier in my career, I learned how end-user decision-makers were driven by how something would look on their CV, and that vendor sales representatives were highly focused on hitting their quarterly targets.

So, a lot of people have been duped into believing they could make these massive, sweeping changes in IT, with life-altering results. Obviously, it can work sometimes, but it isn’t a coincidence that most happy case studies come from smaller organizations because they’re of a size that can actually succeed.

Technology done right can achieve great things, but success can’t be guaranteed by technology alone. Sounds glib, right? But to the point: the problem is not the tech, it’s the complexity of the problem, plus the denialism that goes with the feeling it will somehow be different this time (cf: the definition of insanity).

Complexity applies to infrastructure—whether in-house and built to last yet frequently superseded, or cloud-based and started as a skunkworks project yet becoming a pillar of the architecture. As a consequence, we now have massive, interdependent pools of data, inadequate interfaces, imperfect functionality, and that age-old issue of only two people who really understand the system.

Unsurprisingly, simplification seems to be a massive theme among many technology providers right now—but, meanwhile, business has plenty of complexity of its own: bureaucracy, compliance issues, cross-organizational structures, conflicting policies, and politics at every level. Have you ever tried to make any substantive change to anything in your business? How did that go for you?

I am reminded of a book I once read about quality management systems—a.k.a. process improvement—by Isabelle Orgogozo. This line, while paraphrased here, has stuck in my head ever since, “You can’t change the rules of a game while playing the game.” Why? Because of the fearful and competitive nature of humanity. If you don’t address this, you will fail.

Let’s be clear—technology creates complexity, and it doesn’t even come close to solving corporate complexity. That’s the bad news. Much as we may want some corporate utopian techno-future to be enabled at the flick of a switch, and as much as we have literally banked on it (and may be doing so again, with LLMs), this is never going to happen. You may want the problem to go away with a tool, but it won’t. Sorry!

Getting Transformation to Work: The Five-Point Plan

So, what to do about it? Can you transform the untransformable, slay the dragons of complexity, and overcome organizational inertia? The answer is, I know it can be done, if certain pieces are in place. Conversely, if those pieces aren’t present, you stand less chance of success. It’s a bit like the sport of curling—achieving goals is as much about removing the things that will cause failure as much as it’s attempting that perfect shot at the goal.

1. Start with the Business Strategy

I know, I know–yawn. We can all fall into a rhetorical black hole if we start down the track of, well, it’s just about the business strategy, isn’t it? That’s game over. It’s always about business strategy.

But that’s the point. In their rush to digital, companies have been losing touch with the tangible. Fine that the business strategy has been digital-first, but not so fine that it has been business-second.

No car company is going to wake up tomorrow and not be a car company. We’ve all heard manufacturers say, “We just sell boxes on wheels,” but that’s a big mistake because people are buying the boxes on wheels and they don’t care about software. You might innovate on the software, but ultimately, people are buying the box.

Technology may augment, automate, and even replace in terms of what we do, but it needs to be an equal partner in why we do it.

That “all businesses are software businesses” thing only works if—and here’s the rub—we don’t treat tech as a solve-all. There is never, ever, any excuse for assuming that the answers lie in the technical, and therefore one doesn’t have to think about business goals too much. We all do it, buying stuff to make our lives better, without thinking about what it is we need first.

An easy win is to address this all-too-human trait first. So, what are your strategic initiatives? What’s getting in the way of them? Start there. Absolutely feed in what tech has the potential to do, it would be insane not to. But put business goals first.

2. Align Technical Initiatives to the Business Strategy

The tool should change the business for the better, or it’s no good. So, what’s the business change you’re looking for? And how is the tool going to help you get there?

GigaOm’s Darrel Kent discusses three types of business improvements in his blog: product innovation, customer growth, and operational efficiency. Obviously, operational efficiency is a big target right now, but so is product and service innovation.

An old consulting colleague and mentor of mine, Steve, used to be brought in when major change programs had gone off the rails. He was a rough, bearded bloke from the north of England, and he would start by asking, “What’s the problem we’re trying to solve here?”

It is never the wrong time to confirm business objectives and to ask how existing initiatives align with and drive them. If the answer is complex and starts to go into the weeds, you already have a problem. Cue another human trait: our inability to change course once it is set—which is why we bring in consultants at vast expense when things have gone wrong. You don’t need to wait for that moment, however; spotting failure in advance is not failure, it’s success.

Current projects might be about cost-efficiency, rationalization, and modernization, which is laudable, but could equally indicate an opportunity lost if all you are doing is looking for savings. So, look for gaps as well, as parts of your business strategy may be underserved. Remember the axiom (which I read somewhere, once) that success comes from cutting back quickest when a downturn happens, and coming out of it fastest when things start looking up.

3. Think about Technologies in Terms of Platforms

Let’s keep this simple: if you don’t have a target architecture, you need one. I’m not talking about the convoluted mess your IT systems are in right now, but the shape of how you want them to be. The more you can push into this technology layer—let’s call it a platform—the better.

This does fit with the adage (which I just made up), “better to be the best in your sector than the best infrastructure engineer.” Yes, you will have to bank on a technology provider or several, so put your time and effort into building those relationships and defining your needs rather than burning cycles trying to keep systems running.

As a five-year plan, look to pin down the platform as a basis for customization to meet your business goals, rather than trying to get your custom solutions into a coherent platform that you can then, ahem, customize. I could spend time now talking about multicloud plus on-premises, but I won’t, not here.

4. Align Platforms to Scenarios and Map to Workloads

How do you know if the platform is going to deliver? Simple: you can work through my SWB (scenario-workload-blueprint) model. OK, there is no such model, I just made it up. But let’s go through it piece by piece, and you’ll see what I’m getting at.

Scenarios
First, scenarios. Think of these as high-level business stories (in DevOps language), or simply, “What do we want to do with the tech?”

Scenarios may be user facing: e-commerce, apps, and so on. Or they can be internal, linked to product development, sales and operations, or others. The point is not so much about what scenarios look like, but whether you have a list of things you can check against the platform and say, “Will it support that?”

Scenarios can also be tech-operational; for example, involving application rationalization, infrastructure consolidation, replatforming, and so on—but the question remains the same.

Workloads
In any case, scenarios beget workloads, which are the software-based building blocks needed to deliver on them. Data warehousing, virtualized infrastructure, container-based applications, analytics, and (that old chestnut) AI all fall under the banner of workloads.

By thinking about (business) scenarios and mapping to (technical) workloads, you’re
reviewing how your nascent technical architecture maps to the needs of your organization. Out of this should emerge some common patterns, hopefully not too many, which we can call blueprints. These can form the basis of the platform’s success.

Blueprints
You certainly don’t want to build everything as a custom architecture, as that brings additional costs and inefficiencies. All we’re doing here is adding a couple of steps to set scope and confirm what can run where. The result—blueprints—can then be specced out in more detail, piloted, costed with confirmed operational overheads, and reviewed for security, sovereignty, compliance, and so on.

Also, and interestingly, very little of this exercise needs deep technical expertise. We’re creating a mapping, not building a new kind of transistor. So, there’s no excuse for keeping this discussion outside the boardroom—if your board is serious about digital transformation, that is.

5. Deliver Based on Practicality

There’s a moment you need to bite the bullet and recognize that you can’t deliver perfection. Of course, you can still take the moonshot, but there’s a strong chance you’ll fly like Buzz Lightyear right before he crashes into the stairwell. You may smother this with a fire blanket of denial, to which I say—even if you’re still set on the summit of Everest, how about you do everything you can to get to base camp first? Several strategies can help you here, though you’ll need to work out your own combination (cf: curling):

• Look for halfway houses to success. What does a partial transformation look like, and how can it succeed? For example, French bank Credit Agricole set up a satellite organization to build an app store; it didn’t try to change the whole bank.
• Build the Pareto platform. This is the 80/20 rule, and it should be your mantra, to deliver a tightly scoped infrastructure that delivers on most of your priority needs, which may be quite boring (like claims processing) but are no less transformative. Everything else is custom.
• Bring in the specialists (but stay in control). You won’t have all the skills in-house, so identify the gaps and bring in people who can fill them. Caveat: you want those skills, so use specialists to guide and support, while developing skills of your own.

Next Steps

Ultimately, the keys to digital transformation are in your hands and in the hands of the people around you. And there’s the crux: while the goal may be digital, the reality and the route are both going to be about people.

We may all want technology to “just work” but that’s like wanting people to “just change” and “just know how to make things different,” which just isn’t going to happen. Recognize this, address it head on, and the keys to digital transformation will be laid at your door.

I’d love to know how well this resonates with your own experiences, so do get in touch.

The post Digital Transformation Not Working? Here’s a Five-Point Plan That Can Help appeared first on Gigaom.

The post The Good, The Bad, & The Techy: Workplace Transformation with Heather MacDonald of Pluralsight appeared first on Gigaom.

Simply put, the GigaOm Radar report is written by engineering leaders to help other engineering leaders make engineering-led decisions.

So many reports we see today are based on market factors such as vendor market share, vendor incumbency, customer share, and so on. But CTOs, VPs of engineering and operations, and data architects all need to know how a product will fit their needs at a technical level. That’s what the GigaOm Radar report sets out to do.

As the video shows, we do rank solutions, just not according to market factors. Rather, we focus on delivery capability, strength of offering across differentiating features and business criteria, and speed of movement according to vendor proactiveness and roadmap.

In addition, there’s no magical place where the best products exist to the detriment of the rest. GigaOm recognizes that some buyers might want a broad platform that covers a wide set of needs reasonably well, and other buyers might want a specific solution to meet a certain need.

For product and service vendors, the GigaOm Radar acts like the solution architect or pre-sales engineer in the (virtual) room, who can discuss end-user needs in more detail and address any technical practicalities. Meanwhile, technology leaders can use the GigaOm Radar as a decision-making framework, which they can apply to their own scenarios.

Fundamentally, the GigaOm Radar is a learning tool to drive purchase decisions. All products have strengths and weaknesses, and the GigaOm Radar makes for more straightforward, facts-based decision-making, optimizing efficiency and reducing deployment risk.

So, settle back, get a beverage of your choice, and dive in. For reference, the video comprises the following:

0:00-4:20—Introduction to GigaOm Radar concepts and purpose
4:20-6:45—Explaining the Leader, Challenger, and Entrant rings
6:45-end—How GigaOm scores and plots solutions, and how prospective customers can build a shortlist

Enjoy! And of course, if you have any questions or feedback, don’t hesitate to get in touch.

The post All About the GigaOm Radar | Explainer Video appeared first on Gigaom.