Building a risk management SaaS venture

Context

Organisation

Sedivio is a publicly listed company that builds software for regulated buyers. It operates in the EMEA region; public-sector and medtech clients are among its principal segments.

Environment

By 2021, security requirements had changed status. They applied to the products and to the company's own operations alike. They had stopped being a differentiator and become a precondition — mandatory elements of nearly every tender procedure. The brief was direct: raise the security capability, and find a way to sell it. Delivery costs were rising either way.

Competitive Landscape

In 2021 Sedivio operated in the most crowded segment of the Polish IT market. Several hundred software houses and staff augmentation firms bid for the same public-sector and financial tenders, differentiated by rate card and specialist availability — both replicable within a quarter. The listed integrators above them carried balance sheets large enough to treat compliance as overhead, and the global consultancies above those sold the security advisory layer at rates the segment could not approach. No direct competitor of comparable size owned a product. Sedivio's revenue that year was 6.4 million PLN, concentrated in public-sector e-health work.

Problem

Situation

• In 2021 the Polish software services market was at its peak. The company's revenue grew from 6.4 to 11.5 million PLN over the following year, and to 15.0 million the year after that. The decision described here was taken while the numbers were still improving.

• Profitability had drawn entrants in faster than demand could absorb them. Barriers to entry in the segment amount to a founder, a recruiter and a rate card.

• The prevailing value proposition — better engineers — cannot be verified before purchase. Where a claim cannot be verified, procurement defaults to price. Margins across the segment compressed accordingly.

• Public market investors had begun to price services businesses well below product businesses on the same revenue. A services company is valued on its earnings; a product business is valued on recurring revenue and the rate at which it grows. That spread is what made venture studios and hybrid models the expected answer rather than an ambitious one, and it is why earnings from service delivery were increasingly being reinvested into software products.

• Regulatory requirements added work to delivery and to the maintenance obligations that followed it, materially extending cost and duration on some projects. The segment's margins were not wide enough to absorb it.

• In 2021 the board resolved to enter enterprise cybersecurity services as an extension of the existing offering.

Boundaries

• The regulatory requirements could not be declined. Declining them meant losing access to tenders.

• They could not simply be met either — not without eroding the economics of the business the company already had.

• Adequate security capability was treated by the market as a quality standard: expected by default, not a premium the company could charge for separately.

Constraints

• Existing capabilities were to be used to deliver value.

• After the initiation stage the programme was to finance itself, through increased sales volume, company valuation, or a competitive position strong enough to attract external investment.

Objective

1. Find the market niche, design the business thesis, then verify and optimise it under a hypothesis-driven development model.

2. Design the commercial model, the sales projection and the cost base, and maintain them as a working P&L through successive changes of pricing assumption.

3. Design the business architecture across its four layers — framework, SaaS, platform, services.

4. Support the fundraising process and conduct investor pitches.

5. Design and start the operating functions: marketing, sales, service delivery.

6. Build the team and prepare it to run the business after handover.

Solution

My role

I began this engagement as a strategic advisor responsible for designing the go-to-market strategy. I presented several options. One of them was the initial concept of a cyber risk management system — Cyrima. It required a security framework capable of adapting its workflows to many different scenarios, and an operator able to design and lead the whole initiative, build initial traction and give the vision enough credibility to attract capital.

The engagement therefore changed shape at each stage of development: first to Non-Executive Director, covering solution architecture and business operations design, and ultimately to interim CEO, covering implementation, execution, sales and investor relations. Across those stages the mandate held three roles at once.

Strategy. Market thesis and niche selection; commercial model, pricing and P&L; financing route; sales and marketing narrative requirements, with oversight of their execution; investor conversations on the product side; sales and partnership meetings.

Architecture. Design of the Cyrima framework and of its adaptation mechanism, parameterised on industry, company scale, regulatory landscape, project category and project scale; lead architect and integrator for the security architecture stream, including verification against standards, legal acts and the reference frameworks in use — ITIL, TOGAF, COBIT 5.

Operations. Product owner for the software stream; build of the security, risk and engineering team, including eight senior security, risk and enterprise architects; training and coaching of the team that would hold the business after the engagement closed.

The engagement closed once the product was publicly available, its development plan was prioritised, the company held early adopters and the interest of a major consulting firm, marketing and sales operations were running, and my responsibilities had been distributed across the client's team.

Reasoning

The problem was not the company's alone. Every organisation under the same requirements pays the same efficiency penalty, and the default remedy — niche security advisory — has a structural defect.

Security quality is not observable at the point of purchase. Its output is a non-event, and the field is narrow enough that buyers rarely hold the competence to assess a supplier in advance. Quality becomes legible several projects later, if at all. Procurement therefore falls back on the proxies it can read: certificates, standards, reference lists. Every supplier acquires the same ones, the proxies stop discriminating, and price becomes the only remaining variable.

On the supply side this creates an incentive to staff engagements with the cheapest talent that clears the certificate threshold. The buyer cannot detect the difference at the time. When the difference surfaces later — often as an incident — the claims process transfers part of the cost back to the supplier, years after the margin that funded the decision was booked and spent. That delay is what keeps the mechanism running. Suppliers capable of better work retreat upmarket or leave the segment, and its average quality falls further.

Treated as an operational problem alone, this had no good answer. Defending the position without a very large scale was not viable, and the margin history of the SMB software development market since 2021 shows how many companies fell into that trap. Three alternatives were therefore set aside:

• A standalone compliance programme. It satisfied the regulator but left the added delivery cost unfunded. Margin erosion was the predictable result.

• A conventional security and risk operations centre. Built to accepted market practice, it introduced fixed costs the segment could not carry. The company would have maintained a capability few of its customers would ever buy.

• A lean, minimum-viable reading. This failed on different grounds. The data involved was too valuable to treat that way, and the approach would have produced no competitive position at all.

Reframe

The question had to change: from how to survive the shift, to how to take a position on it — on the assumption that most companies would lack the nerve to act acquisitively while the market was turning. Stated operationally: how to deliver full regulatory compliance for an implementation service that any client can assess during a sales conversation, at a price below traditional consulting, and use the implementation itself as a proof of concept for the tool, with the option for the client to apply that tool independently to any other project or IT change requiring protection.

Three conditions made the question answerable:

• Repetition. The company's engagements were repetitive in approach and scope. Much of the added security work was therefore automatable.

• Build, not buy. The company already held strong internal development capability. It could build those automations rather than purchase them. What it lacked was the structure of the process to be automated.

• Capital timing. It was listed in a market that rewarded technology service businesses moving towards productised revenue. The slowdown in traditional software development was openly acknowledged, and investors were looking for companies with a plan to scale beyond services.

Each condition on its own was unremarkable. Together they meant the company could convert a cost it was already carrying into a product it could sell, using engineers it already employed, in front of investors already looking for exactly that conversion. The consequence was financial before it was operational.

Asymmetries

A straight implementation of the regulatory requirements would have been a modest line item, written off against margin. The programme that was actually funded was budgeted at 8 million PLN across development, marketing, sales and delivery.

What changed was the category of the spend. An expense charged to delivery cost is judged against the current year's margin. An asset developed for sale is judged against the multiple the market applies to product revenue — and that was the pocket investors in a listed services company were prepared to open.

The financing route was chosen on the record against three criteria: speed to build and then scale, protection of the company's other commitments, and shareholder value. Grants and debt were weighed and set aside. The company went to its shareholders with a share issue ring-fenced for development, and the remainder was funded from operating profit and from private investors.

Solution Architecture

The solution had four components.

Cyrima framework — a set of processes, standards and operating instructions, expressed as Jira tasks, which collectively functioned as a PMO operating model with nodes responsible for governance, security, risk and business continuity management. Each process was designed in three variants adapted to company size. Each operating instruction further adapted its scope and approach to project category, scope and risk appetite. Compliance requirements were mapped onto this structure according to the customer's area of operations and industry.

Process management platform — visually similar to Wikipedia, a place that allowed users to move between a single task description, available as a Jira task, and the broader view of a process stage, a whole process, or a whole operating model spanning several interrelated processes. It showed the project stage, current responsibilities and decision architecture.

Jira plugin — the interface most users associated with the brand. Atlassian software served as the backbone for presenting detailed workflows. Cyrima provided an alternative project creation path, including questionnaires that gathered the information the framework needed in order to adapt to the specific project the customer was planning. It generated a complete backlog of tasks assigned to predefined roles, with quick switching between the task view and the process or operating model perspective.

Service marketplace — visible only to partners, it allowed customers to request expert support whenever they needed help securing a project. Because the customer's processes were known — the framework had supplied them — and the required work was known, since the customer selected specific tasks from a generated backlog, scope could be defined and delivery automated to a degree unavailable to a staff augmentation agency. In a market with a persistent shortage of specialists, this precision about the competences an engagement required opened the supplier pool considerably. The marketplace served Sedivio first as a services selling engine. The functionality to admit external suppliers was built and working at launch; its activation was gated on installation volume, on the standard two-sided platform condition that value on each side is set by participation on the other.

Together the components allowed customers to open new projects in Jira with predefined security tasks, from project initiation through to production, aligned with a project management workflow available as a wiki — all adapted automatically to the specific case. Scoping an equivalent exercise through a consultancy takes roughly a month of elapsed time before a document exists. Cyrima produced it in seconds, at a level of detail, with examples and references, that no consulting engagement matched, and at an accuracy close to that of an average practitioner. The basic configuration delivered regulatory compliance alone. The most stringent configuration delivered a full enterprise security posture with auditability, decision tracking, iterative testing and risk activities embedded into every stage boundary.

Commercial model

The model was built for investor conversations and revised as pricing assumptions changed. At handover it stood as four tiers: freemium for small organisations, standard for SMEs up to one hundred accounts, enterprise up to five hundred, and custom above that. SaaS access was sold on subscription; services bought through the marketplace were sold on time and materials or fixed price.

The freemium tier addressed a specific market failure. Regulators required small accounting firms, e-commerce operators and cooperative banks to commit resources those organisations could not afford. By offering an adequate standard at no cost, Cyrima could become the default for a population that had the obligation and no viable way to meet it — and whose method of meeting it nobody was scrutinising.

Implementation

Sequence

Strategy formulation and scenario selection ran across the turn of 2021 and 2022. Fundraising and investor meetings occupied the first quarter of 2022. Work on solution architecture began at the start of the second quarter. Implementation work accelerated sharply around the turn of 2022 and 2023, and 2024 was a year of sustained development effort against the launch date. The third and fourth quarters of 2024 covered the launch, the design of sales and marketing operations, and the handover of responsibilities in preparation for exit.

Team

Two of the parent company's leading engineers — an analyst and an architect — were moved permanently onto the programme, and the marketing function was transferred across with them. The rest of the team was recruited externally, reaching close to thirty people at peak, and that was the hardest part of the build. Some searches ran for eight months. Several of the senior roles — people with 15+ years of experience, leading domain specialists — were won on the concept rather than on compensation.

Hypotheses under test

The programme was delivered using a hypothesis-driven development approach, with Analysis of Competing Hypotheses and Robust Decision Making used to navigate conflicting feedback. Software was developed under SCRUM. Sales operations were built on Consultative Selling and Sandler.

The hypotheses carried through that process, and revised against feedback from the existing customer base, covered:

• the substantive scope of the framework, and the mechanism by which it adapted;

• the degree of formalism appropriate where risk requirements were highest;

• the sales model and the price list;

• whether to open the marketplace to external suppliers or hold it as a proprietary sales engine;

• which motivations the distribution model should be built on.
  
  

Result

Outcome

Development began in 2021. Completion was financed through a share issue in November 2023 with the majority of proceeds ring-fenced for Cyrima and its associated services. Early adopters have been working with a prototype since late 2023.

The system passed Atlassian's verification process in June 2024 and qualified for sale on the Jira marketplace, following functional and penetration testing. General availability followed on 19 August 2024, through an application and a Jira plug-in. Sedivio's announcement credited the product to a collaboration between Sedivio and Selling Security — the brand under which I operated at the time, and the predecessor of Metastrategy — acting as originator and architect of the solution and the partner responsible for strategy and information security.

Cyrima became the company's flagship product and the central subject of its investor communication. The 2024–2025 strategy set a target of at least 15 per cent of annual revenue from cybersecurity, growing above 40 per cent a year. The company continues to develop and sell the system under its own ownership.

Business impact

At the close of the engagement the company held: a product in general availability on the Atlassian marketplace; a development plan, prioritised; early adopters in two segments, a transaction services operator and a legal services firm taken on in the distributor category; a security, risk and engineering capability that had not existed three years earlier; a financing round completed on the strength of the product thesis; and a position in a product category, in place of a position in a staff augmentation category.

The concept also drew interest from the technology arm of a global strategy consultancy. That interest was structural. Strategy firms carry a persistent problem placing the operational half of their engagements: large delivery firms displace them from the strategic work, and small ones deliver at uneven quality. A small firm carrying Cyrima's standardisation resolved both objections. The conversation did not reach a formal agreement.

As an engagement, the project was recognised and awarded by the Interim Management Association in 2025.