Tag Archive for: General

You are here: / / General

Posts

ISA VDA 6.0.3 – The Data Protection sheet explained

/in

The Data Protection catalog is the shortest of the three in ISA 6.0.3 and the one most often underestimated.

Twelve control questions across eight subchapters, all numbered under chapter 9. Compared to the roughly sixty questions in Information Security, it looks like an afterthought.

It isn’t.

It is the part of the assessment where an auditor stops asking how your systems are built and starts asking who told you to process this data, what you agreed to, and what happens when someone asks you to delete it.

 

Three things about this catalog are worth knowing before reading a single control:

  • First, it never stands alone. The sheet says so in its own header text: an isolated assessment of the data protection module cannot lead to TISAX certification. If your customer asks for the “Data” or “Special data” label, you are assessed against the Information Security catalog and the Data Protection catalog together. The Participant Handbook confirms the same mapping.
  • Second, everything here is a must. The Information Security sheet has four requirement columns covering must, should, and additions for high and very high protection needs. The Data Protection sheet has one, and it is the must column. For both the “Data” and “Special data” labels, only that column applies. There is no should-level cushion and no tiering. The difference between the two labels sits entirely on the Information Security side, where “Special data” pulls in the very high protection need requirements marked with a C for confidentiality. The Data Protection questions themselves are identical either way.
  • Third, the whole catalog is written from the position of a processor under Article 28 GDPR. Both labels are defined that way. The controller is your customer, usually an OEM or a tier-1, and a surprising number of the requirements are about the relationship rather than about your infrastructure. If your organisation is the controller for the data in scope, several of these questions will feel oddly angled, and you should raise that with your audit provider early rather than improvise answers.

The target maturity level is 3 for every question, same as the rest of ISA. Level 3 means the process is defined, documented, and actually followed, not that it is world class.

A last practical note: the support columns that make the Information Security sheet easier to interpret, the ones with example questions, example evidence, and references to other standards, are empty for the entire Data Protection sheet in 6.0.3. There is exactly one assistance note in the whole catalog, attached to the processing directory question. You are reading the raw requirement text without the usual scaffolding, which is part of why this sheet feels harder than its length suggests.

9.1.1 To what extent do data protection policies exist?

The stated objective is that the organisation needs at least one policy on privacy, that this policy reflects how seriously data protection is taken, and that it is adapted to the organisation. The sheet adds that further policies may make sense depending on your size and structure.

The requirement is one sentence. A policy is created, kept up to date through regular review, and approved by management.

For an engineering director this is the least interesting control in the catalog and the easiest one to fail on a technicality. What auditors find is usually not the absence of a policy but a policy that was written once, signed by someone who has since left, and never revisited. Management approval means the approval is traceable to a person with authority, and regular updating means there is a review interval you can name and evidence of the last review having happened. A document with a version history and a named approver clears this. A PDF on the intranet with no owner does not.

9.2.1 To what extent are the responsibilities for data protection organized?

The objective is short: successful data protection needs clear responsibilities.

The requirement list behind it is the longest in the catalog. A data protection officer is appointed where Article 37 GDPR requires one, and you have to have actually determined whether the appointment is mandatory or voluntary rather than assuming. If no DPO is required, you still name a data protection function or something comparable. Contact details are published, for example on your website. The role is integrated into the organisational structure. The monitoring obligations under Article 39 (1) (b) GDPR are carried out and documented. The data protection status is documented and reported to top management. The function has enough capacity and resources, which the sheet breaks down into whether the role is full time or part time, professional qualification, regular training, access to specialist literature, and support from data protection coordinators in individual units such as marketing, sales, HR, logistics and development, depending on company size.

The part product managers tend to miss is the reporting line. It is not enough that someone holds the title. There has to be evidence that this person periodically tells the leadership team where the organisation stands, and that they have the time and training to know. A DPO who is also the head of IT and spends four hours a year on the role will struggle here, and so will one who has never attended a training since being appointed.

9.3.1 To what extent are processing activities identified and recorded?

The objective is accountability and transparency, and having an overview of what data processing actually happens.

Where the law requires it, you keep a record of processing activities under Article 30 (1) or Article 30 (2) GDPR, and it is current. The sheet is specific about the processor case: for the Article 30 (2) record you document what relates to the customer’s mandate, expressly not other details of your internal processing. The technical and organisational measures needed for each processing activity, the ones the Information Security catalog asks about, are implemented adequately for those activities. There is a written process description with defined responsibilities, meaning a defined way that new processing gets added to the record and existing entries get reviewed.

This is the only control in the catalog with an assistance note. It says you do not need to list every information asset individually and that categories are acceptable, giving employee master data owned by HR as the example. That note saves a lot of wasted effort. Teams routinely try to build a record at field level and give up halfway. Category level is what is being asked for.

The link to information security matters here and is easy to overlook. The record is not just an inventory. Each entry carries a claim about the controls protecting that processing, and an auditor can walk from a line in your record into the Information Security catalog and ask you to demonstrate the control.

9.4.1 To what extent is adequate handling of high-risk processing activities ensured (data protection impact assessment)?

The objective describes securing high-risk processing in cooperation with the service provider, using measures that identify and where necessary reduce risks to the rights and freedoms of data subjects.

Three things are required. You know which of your processing activities need a data protection impact assessment. Those assessments are carried out. Responsibilities, tasks and the available support during a DPIA are defined and known inside the organisation.

The first point is the one that fails. Knowing which activities trigger a DPIA means there is a screening step somewhere, usually a threshold check when a new processing activity is registered or a new product feature touches personal data. If your answer is that nothing in your scope has ever required a DPIA, the auditor will want to see how you reached that conclusion rather than accept it. For product managers, the useful takeaway is that the DPIA question belongs early in a feature lifecycle, not at launch review.

9.5.1 To what extent is the transfer of data managed?

The objective is that the company knows and secures its data transmissions.

The requirement is that appropriate processes and workflows exist for transferring data, and the examples given are valid Article 28 contracts, suitable transfer instruments such as standard contractual clauses, transfer impact assessments, and adequacy decisions. A sub point covers making sure the consent or the right of objection of the responsible party is respected when work is subcontracted.

Read this as contract hygiene with a process attached. The auditor is not only checking that a data processing agreement exists for a given customer. They are checking that there is a repeatable way these agreements get created, checked and stored, and that engineering does not start moving data before that step is complete.

9.5.2 To what extent are contractual obligations passed through to and enforced at subcontractors and cooperation partners?

The objective is that the company is aware of and secures data transfers to its subcontractors.

What you agreed with your customer is passed on to your sub-processors and cooperation partners. Compliance with those agreements is reviewed rather than assumed. Contact details for the people at the subcontractor are on hand and current.

This is where cloud services, analytics tools and offshore development partners surface. The obligations flow down the chain unchanged, so a commitment you made to an OEM about deletion timelines or breach notification has to appear in the contract with the vendor you rely on to meet it. The review element is what most organisations lack. Signing the contract is evidence of the first requirement. Something like a periodic vendor check or a documented review of a supplier’s certifications is evidence of the second.

9.5.3 To what extent are data transfers to third countries managed?

The objective is that the company is aware of and secures transfers to third countries.

Transfers outside the EU or EEA are known and systematically recorded, for example through the processing directory. Sufficient guarantees under Chapter V GDPR are in place, taking into account the decisions of the European Court of Justice on international transfers, and a transfer impact assessment where relevant, particularly when you act as data exporter. For each third country transfer, it is determined whether the responsible party’s consent has to be obtained.

The word systematically is doing real work. A list assembled once for the audit is not a system. The expectation is that a new third country transfer cannot appear without the record being updated, which in practice means the question is asked when a vendor is onboarded or a region is added to a deployment.

9.6.1 To what extent are data subject requests processed?

The objective is timely handling and fulfilment of data subject requests so that the rights guaranteed by law are protected.

Requests are handled in a timely manner. Procedures exist that let you assist the controller in responding. Employees are trained to immediately pass an incoming request to the responsible person and agree the next steps with them.

The employee training piece is the practical core. As a processor you are not usually the one answering the data subject, but a request can arrive at any inbox in the company. Someone in support or sales needs to recognise it and route it within hours, not discover it in a backlog three weeks later. If your customer has a thirty day clock, your internal handoff has to be measured in days.

9.6.2 To what extent are data protection incidents processed?

The objective is limiting damage to data subjects, preventing recurrence, and making sure the legally required documentation and, where necessary, timely notification to the supervisory authority happen.

Data protection incidents, with unauthorised access to personal data given as the example, are handled in a timely manner. The requirements in chapter 1.6 of the Information Security catalog, the incident and crisis management chapter, also cover data protection incidents, or you have a separate emergency plan for them. Beyond that, documented procedures cover immediate notification of the responsible party where their mandate is affected, documentation of what was done during the handling, employee training on those procedures, and support to the controller while they process the incident.

This is the control most worth building around your existing incident process rather than alongside it. ISA explicitly allows the 1.6 process to carry data protection incidents, which is the cheaper path and the one that actually works during an incident. What you have to add is the privacy dimension: a trigger that recognises when an incident involves personal data, a notification path to the customer fast enough for them to meet their own reporting deadline, and a record of what was decided and when.

9.7.1 To what extent are employees obliged to maintain confidentiality?

The objective notes that organisations are bound by laws, regulations and internal policies, and that at hiring, during employment and at termination it matters that employees commit to following them.

Employees whose work includes processing personal data are placed under an obligation of confidentiality that survives the end of the employment relationship, and are obliged to comply with applicable data protection law. The obligation is documented.

The documentation requirement is the whole control. A clause in an employment contract works. A signed separate undertaking works. An onboarding slide deck does not.

The scope is anyone whose tasks involve personal data, which in most companies is broader than the engineering team.

9.7.2 To what extent are employees trained in data protection?

The objective is direct about the risk. If employees do not know the requirements and the risks, they will behave incorrectly and harm the organisation. The sheet asks for data protection to become a natural part of how people work.

Employees are trained and made aware. Scope, frequency and content follow the protection needs of the data involved. People in critical areas, with IT administrators named as the example, get instruction and training specific to their work, which can take the form of dedicated courses, instructions or short videos.

Two levels of training, in other words. General awareness for everyone, and something targeted for the roles with elevated access. An annual click-through course delivered identically to the entire company satisfies the first half and not the second. The formats named in the requirement are deliberately modest, so a fifteen minute recorded session for the admin team, with attendance recorded, is enough.

9.8.1 To what extent are instructions of processing relationships handled?

The objective is that instructions from the controller are handled in an orderly and defined way, so that the processor’s tasks are fulfilled and the contractually agreed obligations are met. The sheet adds a specific purpose: to identify when something goes beyond what was contractually agreed.

Instructions from the controller about processing personal data are handled. Procedures and measures make sure that received instructions are documented, that they can actually be carried out, with correction and deletion given as examples, and that data is separated by client and by specific order or project.

This is the control that most directly touches system design, and it is the one where an architectural decision made years ago can be expensive. Separation by client and project has to be real. If customer data from three OEMs sits in one table distinguished only by a tenant column that nobody enforces, this requirement is where that shows up. The ability to implement an instruction is equally concrete. If a controller instructs you to delete a specific data set, you need a way to do it and evidence that the deletion happened, including in backups and in downstream systems.

The documentation of instructions is the part teams skip. An instruction arriving as a message in a shared channel and acted on by whoever saw it first is not a documented instruction. The auditor is looking for a channel, a record, and a way to tell later that an instruction was received, who acted on it, and what was done.

Where the effort actually goes

Reading the twelve questions in order gives a misleading impression of the work. Roughly half of them, the policy, the responsibilities, the confidentiality obligation and the training, are documentation and organisation, and a company that has already done ISO 27001 work will move through them quickly.

The other half, the processing record, the DPIA screening, the third country transfers, the incident path and the handling of instructions, need something to exist in the way the company operates, and that is where the months go.

If you are preparing for a “Data” or “Special data” label and want a single place to start, start with 9.3.1. The record of processing activities is what the auditor will use to navigate everything else, and building it honestly tends to reveal which of the other eleven controls you have and which you only think you have.

The post ISA VDA 6.0.3 – The Data Protection sheet explained first appeared on Sorin Mustaca – Security & Technology.

AI Adoption for companies in the USA

/in
This is the extension of the original article AI Adoption for companies (based on OECD data)

What US Companies Are Actually Spending — And Where It Maps

The OECD data gives you the strategic framework. US-specific data gives you a reality check on spending. Here is what verified US sources report.

 

Adoption in the US right now

The US picture differs from the OECD aggregate in one notable way: adoption is accelerating faster than the global average, but the distribution is highly uneven.
The SBA’s Business Trends and Outlook Survey (BTOS) — which draws on Census Bureau data — found that small business AI usage rose from 6.3% in February 2024 to 8.8% by August 2025. Large firms (250+ employees) were at 11% as of February 2025 by the same measure. This is a  narrower gap than the OECD’s global data, where large firms are at 40%. The difference reflects measurement methodology: the BTOS captures active business-function use, while the OECD counts any AI tool use.
The U.S. Chamber of Commerce uses self-reported surveys and gets higher numbers: 58% of small businesses said they use generative AI in 2025, up from 40% in 2024 and 23% in 2023.
These figures are not contradictory — they reflect different definitions of “using AI.” The SBA measures structured business-function deployment. The U.S. Chamber captures self-identified use of any generative AI tool, including consumer apps.
For practical planning purposes, the SBA/BTOS data is more conservative and likely more relevant to real operational deployment.

 

What US firms are spending per employee

The most useful spending data comes from a May 2026 Federal Reserve Bank of Atlanta study, based on a survey of senior US business executives conducted in March 2026.
Key findings:
– US firms spent $1,358 per employee on AI in 2025 (includes software, subscriptions, hardware, training, and IT support)
– That figure is expected to rise to $2,068 per employee in 2026 — a 50% increase year-over-year
– Aggregate private-sector AI investment is estimated at $280 billion for 2026, consistent with a separate Stanford HAI estimate of $285 billion
The distribution matters here. The median firm expects to spend no more than $200 per employee in 2026. The top 10% of firms plan to invest at least $2,800 per employee. That is a 14-fold gap between the median and the leading adopters.
This matches the OECD’s warning exactly: most companies are not spending meaningfully. The average is pulled up by a small number of large, aggressive adopters.

 

How US spending maps to the four strategies

OECD strategy level Typical US company profile Implied spend/employee (Atlanta Fed)
AI Novice Most US SMBs today ~$200 or less (median firm)
AI Optimiser Active adopters, multi-function use $500 – $1,500
AI Explorer Knowledge-intensive sectors (professional services, finance) $2,000 – $3,500
AI Transformer Top 10% of firms, enterprise-wide deployment $2,800+

Source: OECD taxonomy (December 2025) mapped to Federal Reserve Bank of Atlanta spending data (May 2026). Spend figures include software, subscriptions, hardware, training, and IT support.

Note: The spend figures are labeled “implied” because the Atlanta Fed reports a per-employee average across all firm sizes — the mapping to OECD tiers is a reasoned connection, not a direct quote from either source.
The median ($200 or less) is explicitly sourced from the Atlanta Fed’s own finding that more than half of respondents expect to spend no more than $200 per employee.
The professional and business services sector is expected to spend $3,470 per employee in 2026 — a 74% increase from 2025. Manufacturing sits at the opposite end at approximately $900 per employee.
Construction, hospitality, and transportation are likely below even that, consistent with the OECD’s sectoral findings.

 

The training gap in the US

The Atlanta Fed data confirms the OECD finding on training. When firms were asked what their AI spending covers, training was included but represents a small share of total spend for most companies. The same SBA research found that skills gaps remain the primary adoption barrier, affecting 46% of US business leaders (McKinsey data, cited by SBA).
The U.S. Chamber found that concerns over cost, compliance, and workforce readiness are the top three persistent barriers — in that order. Workforce readiness is a training problem. It does not resolve itself with more tool licenses.

 

The US-specific warning on attitude vs. spending

The U.S. Chamber found that 96% of small business owners plan to adopt emerging technologies including AI.
That intention figure is strikingly high. But intention and spending are not the same thing. The SBA/BTOS data shows actual structured deployment at 8.8% for small firms.
The gap between 96% intent and 8.8% deployment is the execution problem. It is the same problem the OECD documents globally.
Companies announce AI plans. Most stay at Novice level or never deploy meaningfully. The reason, consistently, is the same: no training program, no governance, no assigned owner, and no defined use case.

Sources

OECD & G7

US Federal & Government Sources

U.S. Chamber of Commerce

The post AI Adoption for companies in the USA first appeared on Sorin Mustaca’s blog.

AI Adoption for companies (based on OECD data)

/in

 

Why You Need to Read This Now

Between 2020 and 2024, the share of firms using AI across OECD countries more than doubled — from 5.6% to 14%. Large firms (250+ employees) are at 40% adoption. Small firms (10–49 employees) are at 11.9%. Mid-sized firms sit in the middle at 20.4%.

That gap is wider than for any other digital technology. For cloud computing or IoT, smaller firms are roughly half as likely to adopt. For AI, it’s more than three times.

If you are a mid-manager, you sit at the execution layer: strategy comes from the top, AI resistance comes from the bottom. You’re the one who has to make it actually work.

This article is written for that position.

 

The Four Types of Companies — Where Does Yours Fit?

The OECD taxonomy organizes AI adoption into four profiles based on digital maturity, complexity of use, and how widely AI is applied across the business.

AI Novice. Using off-the-shelf tools (ChatGPT, Copilot) for isolated tasks — writing, marketing, simple process support. Leadership has heard about AI but no formal strategy exists. Most SMEs fall here today.

AI Optimiser. AI is used systematically across several departments. There’s coordination and some governance. Adoption covers content, customer service, and workflow efficiency.

AI Explorer. Custom AI models are being built or fine-tuned on internal data. Use cases are sector-specific. The team experiments with agents and automated pipelines.

AI Transformer. AI is embedded enterprise-wide, across operations and decision-making. In-house technical expertise exists. Infrastructure is unified.

The taxonomy matters because the right strategy — and the right costs — depend entirely on which category you’re in, or which you’re trying to reach.

 

Keep this in mind:

One size does not fit all: firms with varying levels of digital maturity may require different instruments to boost their capabilities and their ability to leverage the potential of AI.

 

Strategy 1: Start as an AI Novice (Off-the-Shelf Tools Only)

What it means

You deploy consumer-grade or SaaS AI tools directly. No custom development. No infrastructure investment. Tools include ChatGPT, Microsoft Copilot, Google Gemini, or vertical-specific tools embedded in software your team already uses.

Real example from the OECD report: a small coffee roaster in San Francisco used ChatGPT for product descriptions, SEO, marketing emails, and shipping cost analysis — entirely self-taught, no budget for specialists.

Financial cost

Item Estimated range
ChatGPT Team or Business $25–$30 per user/month
Microsoft 365 Copilot (if already on M365) $30 per user/month
Google Workspace with Gemini $20–$30 per user/month
Typical annual cost for a 20-person team $6,000–$10,000/year

These are subscription costs only. No infrastructure. No data work. No custom code.

You can start with 5–10 users before rolling out to the whole team. Most tools have free tiers for initial testing.

Training cost

This is where companies systematically fail. The OECD found that under 30% of SMEs using generative AI report providing any AI-related training to employees. Japan is at 11.3%. Germany at 23.2%. The UK at 24%.

For AI Novice rollout, training is not optional if you want results. The research shows that firm-provided training and employer encouragement significantly boost workers’ use of generative AI and reduce demographic gaps in use (OECD D4SME Survey, 2025).

Minimum training investment at this level:

Training type Cost estimate
External prompt engineering workshop (half-day, group) $1,500–$4,000 one-time
Online course per employee (Coursera, LinkedIn Learning AI courses) $300–$500/person/year
Internal champion — one person designated to run practice sessions Time cost: ~2–4 hours/week
Total for 20-person team, first year $8,000–$18,000

The time cost is often underestimated. Expect 4–8 hours per employee in the first three months to reach basic competency. That’s real productivity loss during the transition period.

What the OECD calls the J-curve risk

The research documents a J-shaped productivity curve: performance may decline temporarily before it improves. Budget for this. It is normal. Teams produce less while learning. This typically lasts 4–12 weeks depending on tool complexity and training investment. Managers who don’t anticipate this tend to abandon tools too early.

What you should do

  • Pick one use case with a measurable output (e.g., first draft of customer communications, meeting summaries, internal documentation).
  • Run a 4-week pilot with 5 people before scaling.
  • Assign an internal champion. This person does not need to be technical.
  • Create a short usage guideline (2 pages maximum) covering acceptable use, data sensitivity rules, and output review requirements.

Strategy 2: Become an AI Optimiser (Cross-Functional Integration)

What it means

You move from isolated tool use to coordinated AI integration across departments. AI is used in marketing, customer service, HR, operations, and finance — not just by individuals experimenting independently.

This requires governance. You need policies on what data goes into AI tools, who reviews outputs, and how AI decisions are audited.

Financial cost

Costs increase significantly here because you’re adding coordination infrastructure, not just tool licenses.

Item Estimated range
SaaS AI tools (expanded seat count) $15,000–$40,000/year for 50–100 users
AI governance tooling (policy management, audit logs) $5,000–$20,000/year
Process mapping and workflow redesign (consulting or internal time) $10,000–$30,000 one-time
Data audit and clean-up (making internal data usable by AI tools) $5,000–$25,000 one-time
Total first-year investment (50-person team) $35,000–$115,000

The OECD report is explicit: the cost of developing AI-ready data should not be overlooked. Most companies discover their internal data is fragmented, inconsistently labelled, or stored in formats AI tools cannot use. This cleanup is expensive and slow.

Training cost

At Optimiser level, training needs are more specific. Employees need to understand not just how to use tools, but how AI outputs feed into business processes and where human review is required.

Training type Cost estimate
Role-specific AI training (tailored by function: sales, ops, finance, HR) $500–$2,000/person
AI literacy program for managers (decision-making with AI outputs) $1,000–$3,000/manager
Change management workshops (handling team resistance) $5,000–$15,000
Ongoing skills refresher budget (tools evolve rapidly) $200–$500/person/year
Total first-year training cost (50-person team) $40,000–$100,000

The OECD survey data identifies the skills that become more important due to generative AI: data analysis and interpretation (cited by 46.4% of firms), creativity and innovation (41.9%), programming and coding (39%), and communication and collaboration (35.8%). Your training program should target these explicitly.

What the OECD says about resistance

Cultural and organizational resistance is one of the documented barriers at this level. The G7 Blueprint is specific: change management is essential to guide teams through AI integration transitions, address opposition, facilitate upskilling, and embed AI into everyday workflows.

Budget for this separately. It is not the same as technical training. Change management at this scale typically requires a structured program over 3–6 months, either run internally by HR with a framework or outsourced to a specialist.

What you should do

  • Build an AI adoption roadmap. The OECD recommendation is explicit: company-level roadmaps should align with overall business goals and articulate where, why, and how AI will be used to drive value.
  • Define a data governance policy before expanding tool use. What can employees input into external AI systems? What is off-limits (personal data, client data, confidential financial data)?
  • Establish a cross-functional AI steering group. Include someone from legal, IT, HR, and one or two operational team leads.
  • Set measurable targets. Productivity gains at this level typically show after 6–12 months. Firms in OECD research showed productivity premiums over 4%, with some above 15%, but only when AI was integrated into core operations — not kept at the periphery.

Strategy 3: Become an AI Explorer (Custom and Sector-Specific AI)

What it means

You begin building or fine-tuning AI models on your own data. Use cases are specific to your business context — custom agents, proprietary analysis pipelines, sector-specific classification or prediction tools.

Real example from the OECD report: a micro wholesale company in Tokyo built custom AI agents for Q&A, project negotiations, and multi-language translated chat, which increased revenues and shortened negotiation cycles.

This requires internal technical capability or reliable external partners. It is not viable without AI-ready data and at least one technically proficient person managing the work.

Financial cost

Item Estimated range
Cloud AI infrastructure (compute, storage, API access) $20,000–$80,000/year
AI development (internal hire or external agency) $80,000–$200,000/year
Data preparation and labelling $15,000–$50,000 one-time or ongoing
Security and compliance infrastructure $10,000–$30,000/year
Total annual investment $125,000–$360,000+

The OECD report highlights a specific market problem at this level: lack of competition among cloud AI infrastructure providers has led to over-reliance on hyperscalers (AWS, Azure, Google Cloud), which makes terms restrictive and costs high for SMEs. This is a real constraint. Plan for it.

Open-source AI models (Meta’s Llama, Mistral, and others) are specifically highlighted in the G7 Blueprint as a way to reduce costs and lower barriers. These require more technical overhead but significantly reduce licensing costs.

Training cost

Technical roles at this level are expensive. The OECD is direct about this: small companies often lack sufficient resources to offer competitive salaries that help attract and retain talent, putting them at a disadvantage compared to larger companies.

Training/talent type Cost estimate
ML engineer or data scientist (hire or contractor) $90,000–$180,000/year salary range
Advanced AI/ML certification for existing technical staff $3,000–$10,000/person
Cross-functional AI training (non-technical staff working with AI outputs) $500–$1,500/person
External AI advisor or mentor (part-time engagement) $15,000–$50,000/year
Total first-year talent and training cost $110,000–$240,000+

The OECD recommends pooled training programs as a cost-reduction mechanism — sharing training costs through industry associations, sector groups, or regional clusters. This is worth exploring specifically if you’re in a sector with a strong industry association.

What you should do

  • Validate the business case before committing to custom development. The OECD documents that many companies move to Explorer level prematurely and get stuck — experiments that never scale.
  • Start with one tightly scoped use case. The G7 Blueprint is explicit: successful projects begin with tightly defined problems that align with business priorities, such as cost savings, efficiency gains, or product improvement.
  • Consider academic partnerships. Embedding AI talent directly within SMEs through internships, residencies, or collaborative projects with universities is a documented cost-reduction strategy in the OECD research.
  • Plan for 12–24 months before reliable ROI. Custom AI development rarely produces measurable returns in under a year.

Strategy 4: Aim for AI Transformer (Enterprise-Wide Embedding)

What it means

AI is embedded across all major operations and decision-making processes. Infrastructure is unified. In-house expertise exists across functions. The business model itself may depend on AI capabilities.

Real example from the OECD report: a healthcare company in Calgary uses large language models, NLP, and computer vision for clinical note transcription and lab report analysis. A Cambridge biotech built a knowledge graph integrating 50+ data sources for drug discovery.

This level is not realistic for most SMEs in the near term. It requires years of foundation-building across the previous three stages.

Financial cost

At this level, AI is no longer a project cost — it’s an operational cost embedded in the business. Typical annual investment profiles in the OECD research context range from $500,000 to several million dollars depending on sector and scale, including infrastructure, dedicated technical teams, data operations, and compliance.

This is not a starting strategy. You reach it by progressing through the previous three stages.

Training cost

The training model at this level is continuous and embedded. The entire workforce undergoes ongoing AI skills development. The OECD frames this as a culture of continuous learning, not a one-time program.

Budget: typically 2–5% of total payroll annually dedicated to training and skills development, with AI literacy as a core component of every role’s development plan.

The Four Non-Negotiable Foundations (Regardless of Strategy Level)

The OECD and G7 Blueprint identify four enablers that are prerequisites for any level of AI adoption. These apply to you regardless of which strategy above you’re pursuing.

1. Connectivity. AI tools require high-speed, reliable broadband. If your team is distributed or includes remote workers in rural areas, audit your connectivity situation before investing in AI tooling. Fixed download speeds in metropolitan areas are 44% higher than in remote areas (OECD data, 2024).

2. Data readiness. Most companies discover their data is not AI-ready. It’s fragmented, incomplete, or stored in formats that AI tools cannot process. This is not a technical problem you can skip — it’s a prerequisite. Budget time and money for a data audit before serious AI investment.

3. Skills. The OECD survey found 50% of SMEs say employees lack the skills to use AI effectively. Training is consistently the most impactful intervention across all G7 countries surveyed. It is the single highest-ROI investment in AI adoption.

4. Governance. Concerns about harmful content (cited by over 90% of US firms), inaccurate outputs, and legal/copyright issues are reported by the majority of firms. Before deployment at scale, you need a brief but real policy: what is acceptable use, what data is off-limits, and how outputs are reviewed.

What the OECD Says About Attitude vs. Actual Barriers

This is worth reading carefully. The research found that 86% of SMEs report either neutral or favorable attitudes toward generative AI. Attitude is not the primary barrier.

The obstacles are practical: skills, cost, infrastructure, and perceived relevance. Many SMEs in Canada and the UK reported believing that AI simply wasn’t suited to their type of work.

As a mid-manager, this is your most direct challenge. The resistance you’ll encounter from your team is rarely ideological. It’s practical: people don’t know how to use it, they’re worried about their jobs, and they haven’t seen it solve a real problem they have. Address those three things specifically and directly. That’s change management.

A Checklist Before You Start

Before committing budget to any AI adoption strategy, work through these questions. They come directly from the OECD’s recommended company-level assessment framework.

  • [ ] What specific business problem are we trying to solve with AI?
  • [ ] What is our current digital maturity? (Are we already using cloud tools, structured data, modern software?)
  • [ ] What data do we have, and is it clean and accessible?
  • [ ] Who internally will own AI adoption coordination?
  • [ ] What is our acceptable-use policy for AI tools, specifically regarding sensitive or confidential data?
  • [ ] What is our realistic budget for tools and training in year one?
  • [ ] How will we measure whether it’s working?
  • [ ] What’s our plan if productivity temporarily drops during transition?

Summary Table

Strategy Who it’s for Year-1 Tool Cost Year-1 Training Cost Time to ROI
AI Novice Any team, starting out $6K–$10K $8K–$18K 3–6 months
AI Optimiser Teams with some AI use, ready to coordinate $35K–$115K $40K–$100K 6–12 months
AI Explorer Technically capable, data-ready teams $125K–$360K+ $110K–$240K+ 12–24 months
AI Transformer Long-term, multi-year commitment $500K+ Ongoing (2–5% of payroll) 2–4 years

Cost ranges are estimates. They vary significantly by company size, sector, geography, and specific tools chosen.

Instead of conclusions: Don’t Skip the Steps

The taxonomy in this report is not decorative. It exists because companies that try to jump from Novice to Explorer — skipping the Optimiser phase — consistently fail to embed AI into real operations. They run pilots that never scale. They buy tools that nobody uses confidently.

Each stage builds something the next one depends on: Novice builds familiarity. Optimiser builds process and governance. Explorer builds technical depth. Transformer builds organizational identity around AI.

The productivity gains the OECD documents — 4% to 15%+ at the firm level — come from companies that moved through these stages deliberately, not from companies that spent the most money the fastest.

Your people need time to understand what the tools actually do before they can use them well. That understanding doesn’t come from a product demo or a one-hour onboarding session. It comes from repeated, low-stakes practice with real work tasks — which is exactly what each strategy level is designed to provide.

Move at the speed your team can actually absorb. That’s not caution. That’s how adoption works.

 

Sources

Based on: AI Adoption by Small and Medium-Sized Enterprises, OECD Discussion Paper for the G7, December 2025

Companion document: The SME AI Adoption Blueprint, G7 Industry, Digital and Technology Ministerial, December 2025

OECD AI Principles: https://www.oecd.org/en/topics/ai-principles.html

The post AI Adoption for companies (based on OECD data) first appeared on Sorin Mustaca’s blog.

SOC 2 Type 2 mapping to Secure SDLC Requirements

/in

We started to talk about the SOC2 Type 2 certification and I feel that we neglected it a bit.

I wrote a bit about SDLC, Secure SDLC in particular, but now it is time to bring them together.

 

SOC 2 Type 2 and Secure SDLC — the big picture

SOC 2 Type 2 evaluates whether controls are operating effectively over time (typically 6–12 months). It is not a point-in-time snapshot.

Your SDLC is not an isolated engineering practice — it feeds directly into several Trust Services Criteria (TSC).

All nine Common Criteria map to the SDLC in some way, but they do so at different layers.

CC1 (Control Environment) is the foundation. It is not about code or process — it is about organizational accountability. The auditor checks that your Secure SDLC has a named owner, that the policy carries formal authority, and that security has a defined role in the development organization. Without this, every other control lacks a governance backbone.

CC2 (Communication) requires that developers know the rules. A Secure SDLC policy that exists but was never distributed or acknowledged does not satisfy this criterion. The auditor looks for training records, policy sign-offs, or equivalent evidence that the people making security decisions in each SDLC phase were aware of their obligations.

CC3 (Risk Assessment) maps directly to the Idea and PoC phases. The criterion requires that risks are identified and analyzed before work begins. A threat model, a risk register entry, or a documented security review of the proposed design all serve as evidence. The auditor wants to see that risk was considered as an input to scope decisions, not evaluated after the fact.

CC4 (Monitoring Activities) requires ongoing evaluation of whether controls are working. In SDLC terms this means SAST, DAST, and SCA scans must run regularly, their results must be reviewed, and findings must be tracked to resolution. Running a scan whose results are never acted on does not satisfy CC4.

CC5 (Control Activities) covers the specific rules that govern how code is written and reviewed. Secure coding standards, mandatory peer review, branch protection, and secrets scanning policies all live here. CC5 is about the guardrails built into the development process itself, not just the approval chain around it.

CC6 (Logical Access) runs across the widest range of SDLC phases. It covers who has access to source code, build pipelines, deployment tools, and production environments — and whether that access is appropriate at each phase. PoC access that was never revoked and production credentials embedded in a repository are both CC6 findings.

CC7 (System Operations) requires that running systems can detect and respond to threats. Its SDLC relevance is that logging, alerting, and incident response readiness must be built into the product before it reaches production. If these are treated as post-launch concerns, CC7 is a gap.

CC8 (Change Management) is the criterion most directly owned by the SDLC. Every code change from PoC through EOL must be authorized, reviewed, and traceable. This criterion generates the highest sample volume in a Type 2 audit — typically 20 to 25 change records — and every sampled item needs a complete evidence chain.

CC9 (Risk Mitigation) addresses third-party and vendor risk. In a software development context this means evaluating open-source libraries, SDKs, and external dependencies before they are adopted. Running a dependency scan satisfies part of this, but CC9 specifically requires that a conscious risk decision was documented — not just that a tool ran.

The practical takeaway is that CC1, CC2, and CC9 are the ones most commonly missing from customers who think their Secure SDLC is well covered.

They focus on CC8 (change management) and CC6 (access) but leave governance, communication, and vendor risk undocumented.

 

Summary mapping of SOC2 controls to SDLC

CC Control Name Idea PoC MVP Release EOL SDLC Intersection / Evidence
CC1 Control environment ✓ — — — — SDLC policy with named owner. Security team has formal authority to block releases.
CC2 Communication ✓ ✓ ✓ — — Secure SDLC policy published and acknowledged. Developer training completion records.
CC3 Risk assessment ✓ ✓ — — — Threat model at Idea phase. Risk register updated before PoC scope is confirmed.
CC4 Monitoring activities — — ✓ ✓ — SAST/DAST results reviewed. Recurring vuln scans in prod. Findings tracked to closure.
CC5 Control activities ✓ — ✓ ✓ — Secure coding standards doc. Code review policy enforced. Branch protection rules active.
CC6 Logical access — ✓ ✓ ✓ ✓ Repo and pipeline access logs. Secrets management reviewed. Prod access revoked at EOL.
CC7 System operations — — ✓ ✓ ✓ Logging enabled pre-release. Alerting configured in prod. Incident runbook referenced.
CC8 Change management — ✓ ✓ ✓ ✓ PR records with approvals. Pipeline gates enforced. EOL change ticket required.
CC9 Risk mitigation ✓ ✓ — — — Third-party libraries assessed. OSS license and security risk reviewed before adoption.

 

Practical Checklist — SDLC Evidence by Common Criteria

CC1 — Control environment

SDLC policy with version, date, and named owner. Org chart showing security’s authority. Evidence security can block a release.

CC2 — Communication

Policy acknowledgment log with names and dates. Annual security training completion records. Re-communication evidence if policy changed during the audit period.

CC3 — Risk assessment

Threat model dated before PoC began. Risk register with severity ratings and owners. Security requirements traceable to backlog items.

CC4 — Monitoring activities

SAST and SCA scan reports on a recurring cadence, not one-off. Vulnerability remediation log showing finding, severity, owner, SLA target, and closure date.

CC5 — Control activities

Secure coding standards document. Branch protection configuration blocking direct pushes to main. Secrets scanning active in the repository.

CC6 — Logical access

User access list per environment with roles. Annual access review log. MFA enforcement evidence. Secrets stored in a secrets manager, not in code. Access revocation records for leavers and decommissioned systems.

CC7 — System operations

Logging configuration in place before first production release. Alerting thresholds and escalation paths documented. At least one security alert triaged and recorded during the audit period.

CC8 — Change management

PR records with reviewer names and approval timestamps for every sampled change. Pipeline logs showing tests passed before deployment. Rollback procedure documented. Change ticket for every production deployment including EOL.

CC9 — Risk mitigation

Dependency evaluation process documented. SCA reports showing library risk at adoption and on a recurring basis. Risk acceptance record for each significant new dependency introduced during the audit period.

Secure SDLC and SOC 2 Type 2 — Summary

SOC 2 Type 2 evaluates whether security controls operated consistently over an audit period, typically 6 to 12 months. A Secure SDLC is not a separate compliance workstream. It is the operational mechanism through which most of the Common Criteria are satisfied.

 

All nine Common Criteria (CC1–CC9) have at least one touchpoint in the SDLC. No phase is audit-free.

Idea is the most governance-heavy phase. CC1, CC2, CC3, CC5, and CC9 all apply here. Before a single line of code is written, the auditor expects a threat model, a risk register entry, a policy that developers have acknowledged, and evidence that third-party dependencies were evaluated. Skipping security at this phase creates gaps that are difficult to close retroactively.

PoC is where CC6 findings most often hide. Auditors check whether PoC environments were isolated from production data and whether access granted during PoC was later revoked. CC8 also applies — even exploratory work needs a change record.

MVP is the most evidence-dense phase and where auditors spend the most time. CC4, CC5, CC7, and CC8 all apply. The auditor will sample pull request records, SAST and SCA scan reports, vulnerability remediation logs, and logging configuration. Controls must have operated on every change, not just most of them.

Release is primarily about authorized change (CC8) and least-privilege access to production (CC6). Pipeline logs are strong evidence because they show controls were enforced automatically. A documented rollback procedure satisfies CC7.

EOL is the most commonly under-documented phase. CC6 requires proof that access was revoked. CC8 requires a change ticket for the decommission. CC7 applies if the system handled live data up to shutdown. Data disposal records satisfy C1.2 if confidentiality is in scope.

The controls most frequently missing in practice are CC1 (no named SDLC policy owner), CC2 (policy exists but was never formally acknowledged by developers), CC7 (logging treated as a post-launch concern rather than a release requirement), and CC9 (dependency risk decisions not documented, even when scans were run).

The key principle for SOC 2 Type 2 is consistency. A control that worked 90% of the time is still a finding. Every sampled change needs a complete evidence chain from its originating phase through to deployment or decommission.

The post SOC 2 Type 2 mapping to Secure SDLC Requirements first appeared on Sorin Mustaca’s blog.

EU Cyber Resilience Act (CRA) – Overview

/in

What is the Cyber Resilience Act – CRA

The Cyber Resilience Act is the first European regulation to set a mandatory minimum level of cyber security for all connected products available on the EU market – something that did not exist before.

The CRA is a regulation from the European Union — formally Regulation (EU) 2024/2847 — but it is likely to be applied soon in other parts of the world, which produce for and sell products in the EU.

It covers both hardware and software products whose intended or foreseeable use involves connection (direct or indirect) to a device or network. That includes things like smartphones, laptops, IoT devices (smart-home cameras, smart fridges, connected toys), embedded systems, routers, industrial control systems, and even software with network connectivity.

Non-commercial open source software products are exempt from the CRA and therefore do not have to fulfill the requirements of the CRA.

Some product categories are excluded because they are already covered by other sector-specific regulation (e.g. certain medical devices, aviation, automotive, defense).

As can be seen, the aim is to increase cybersecurity within the European Union. The new regulation applies in all EU Member States and will be implemented gradually.

Timeline & Legal Effect

The CRA entered into force on 10 December 2024. There is a transition / compliance period: the full requirements become applicable by 11 December 2027 for new products.

Starting 11 June 2026, the Conformity Assessment Bodies can assess the fulfillment of the requirements.

Reporting of vulnerabilities and security incidents starts on 11 September 2026.

*CABs = Conformity Assessment Bodies

Source: BSI

Key Requirements & Obligations

For manufacturers, importers or distributors of in-scope products, CRA demands:

Secure-by-design and secure-by-default

During design and development, implement baseline cybersecurity controls (minimizing attack surface, secure defaults, applying cryptography, access control, integrity protection, etc.).

If you design or manufacture hardware or software intended for the EU market — start including security early: threat modelling, secure defaults, update mechanisms, patch management, SBOM (software-bill-of-materials) for components, documentation.

Lifecycle security

Maintain security across the lifecycle — through production, deployment, maintenance, updates (patches), and eventual decommissioning.

Prepare to collect and maintain documentation of the build, supply chain components, update/maintenance history, and test results for many years.

Vulnerability & incident reporting

If a product becomes subject to a “actively exploited vulnerability” or a “severe security incident”, the manufacturer must report promptly (early warning within 24 h, full notification within 72 h, final report within certain timeframes) via the CRA Single Reporting Platform.

For software vendors — ensure update/patch infrastructure is robust and built-in, and notification processes in place for vulnerabilities.

Documentation & traceability

Maintain technical documentation, data inventories and evidence of security measures for a defined period (often many years) after placing the product on the market.

CE-marking with security

Products that comply must carry the CE-mark, indicating conformity with the CRA’s cybersecurity requirements — similar to CE marking for safety or environmental compliance.

For buyers/customers — expect CE-mark + transparency regarding security posture. Choose vendors who commit to long-term patching and vulnerability response.

Conformity assessments for higher-risk products

While many products (roughly 90%) fall under a “default” tier and can be self-assessed by manufacturers, certain more critical or important product types (e.g. firewalls, security modules, intrusion detection systems, certain embedded systems) may require third-party assessment before being placed on market.

Why It Matters

The CRA establishes a common, EU-wide baseline for cybersecurity of digital products. This helps avoid fragmentation where different member states might otherwise have different rules. It forces manufacturers and vendors to adopt security by default + lifecycle security, rather than treating cybersecurity as an optional afterthought. This helps reduce the attack surface and improves resilience against cyber threats.

It increases transparency for consumers and businesses: when they buy a product with digital elements, they can expect a baseline of security and support — including updates and vulnerability management.

For vendors and developers — in enterprise, embedded, IoT or consumer space — it’s a legal obligation. Non-compliance when required could lead to regulatory consequences, and non-compliant products will not be allowed on the EU market once the deadlines lapse.

 

CRA Product Classification

Criteria & Examples

The CRA divides “products with digital elements (PDEs)” into four classification tiers. Classification drives what conformity assessment, certification, and compliance rigour you must apply.

Category When a product is placed here (criteria / rationale) Typical product examples*
Default Products that are not listed in the “Important” or “Critical” annexes — i.e. no particularly sensitive cybersecurity function or high risks associated with compromise. Many consumer devices & software: smart toys, basic IoT devices, simple smart-home equipment, non-security-critical apps, common consumer electronics.
Important – Class I PDEs that provide a cybersecurity-relevant function (authentication, access control, network access, system functions) but whose compromise would have a moderate risk (less than Class II). Identity management systems / privileged-access software or hardware (e.g. access readers), standalone/embedded browsers, password managers, VPN clients, network management tools, operating systems, microcontrollers/microprocessors with security-related functions, routers/modems/switches.
Important – Class II PDEs whose function involves a significant cybersecurity risk, or whose compromise could have wide or severe impact, especially on many other systems — thus higher criticality than Class I. For these, third-party conformity assessment is mandatory. Firewalls, intrusion detection/prevention systems (IDS/IPS), virtualisation/hypervisor/ container runtime systems, tamper-resistant microprocessors/microcontrollers, industrial-grade network/security systems.
Critical PDEs with cybersecurity-related functionality whose compromise could disrupt or control a large number of other products, critical infrastructure, supply chains or sensitive services. These must either get an EU cybersecurity certificate (per relevant scheme) or undergo strict third-party assessment. Hardware security modules (“security boxes”), smart meter gateways, smartcards / secure-elements, secure cryptoprocessing hardware — i.e. devices central to critical infrastructure, secure identity, secure communication or supply chain security.

* These examples reflect currently published annex examples and guidance. Regulatory technical specification updates (e.g. by the European Commission) may refine or expand the lists.

 

Assessment & conformity requirements per class

Below are examples of software products affected by the Cyber Resilience Act, organized into two tables and classified into the CRA categories:

  • Default Category – non-critical, low inherent risk

  • Important Class I – higher exposure, widely deployed, could be abused at scale

  • Important Class II – products with elevated security relevance, including security software and products in Annex III

  • Critical – core components of cybersecurity, identity, encryption, or essential network infrastructure

These classifications follow the CRA’s conceptual tiers, not an official certification list, because exact classification depends on the manufacturer’s intended use and applicability of Annex III.

Examples of Software Products Classification

Disclaimer: this is my current understanding of products with digital elements (PDEs). There is no official list of categories of products published, or at least I did not find one.

This list was created with help of AI and it is no guarantee to be complete or correct.

 

Software Type Example(s) CRA Category Rationale
CRM Platforms Salesforce, HubSpot, MS Dynamics Default General business software; no direct security function.
Blogging/CMS Platforms WordPress, Ghost, Drupal Default Consumer and enterprise web software; not security-critical by default.
Office Productivity Tools LibreOffice, MS Office Default Widely used but not security components.
Developer Tools IDEs, build systems Important Class I Used in software supply chains; compromise impacts downstream.
Cloud Management Consoles AWS CLI tools, Azure Portal extensions Important Class I Access to infrastructure; security implications.
Antivirus / Endpoint Protection CrowdStrike, Defender, Bitdefender Important Class II Security products explicitly listed under risk-sensitive categories.
EDR/XDR Platforms SentinelOne, Trellix, Microsoft XDR Important Class II Security monitoring and threat response capabilities.
Firewalls (Software-based) pfSense, OPNsense, Cisco, Juniper Important Class II Security enforcement components.
VPN Clients OpenVPN Client, WireGuard clients Important Class II Encryption and secure communications; directly covered.
Identity & Access Software SSO, MFA clients, IdP agents Critical Core identity systems; high systemic impact.
Key Management & Crypto Libraries OpenSSL, libsodium Critical Cryptographic primitives/implementations; part of critical components.
Secure Configuration Agents MDM agents, compliance agents Important Class II Affect system posture and policy enforcement.
Network Monitoring / SIEM Splunk, Elastic, QRadar Important Class II Security event analysis and detection.
Container Security Tools Aqua, Twistlock Important Class II Protect containerized workloads; tied to infrastructure security.

 

Further reading and sources

The post EU Cyber Resilience Act (CRA) – Overview first appeared on Sorin Mustaca’s blog.

From Idea to Proof of Concept to MVP: The POC stage (2/3)

/in

We continue the series of 3 articles with the second one, about the Proof of Concept (POC).

Here is the first article in the series, From Idea to Proof of Concept to MVP: The Idea stage (1/3) .

2. The Proof of Concept (POC)

The POC is where the team tests a specific risky assumption that could make or break the idea.
The aim is not to build a usable product but to verify that a key technical, architectural, or data-processing challenge is solvable.

POC code is intentionally imperfect. It moves fast and cuts corners. However, it should still be written in a way that reduces friction when extracting reusable parts for the MVP.

What Defines a POC

  • A POC is short-lived and narrowly focused. It often tests only one or two questions:
    Can we integrate with this external system?
  • Can this algorithm scale?
  • Can the frontend render a dynamic timeline with the required performance?

The purpose is to generate a clear yes/no answer, not to produce a polished outcome.

Inputs and Outputs

Inputs include the problem statement and hypothesis defined in the idea stage.
Outputs include a working demonstration, documentation of findings, architectural constraints, and a clear decision: continue, pivot, or stop.

Actors

Developers implement the experiment.
Tech leads help evaluate results.
QA may help with validation but does not perform full product testing.
Security engineers review risks that appear during the experiment.

Engineering Expectations at This Stage

Code and Reuse

POC code is disposable, but that does not mean it should be sloppy. Developers should write code that can be extracted later without major re-architecture. This typically means:

  • Avoid hardcoded credentials, external URLs, or secrets.

  • Organize files in a simple but meaningful structure.

  • Implement the core logic in isolated modules instead of burying it inside an ad-hoc script.

  • Use interfaces or adapters to make future dependency injection easier.

The mindset should be: “This code may be thrown away, but if it works well, we want to reuse pieces of it.”

What Must Change Later

Before integrating POC code into the MVP, the team will need to refactor it: add error handling, consistent logging, tests, and proper abstractions.
In other words, the POC shows the core idea works, but the MVP requires turning this into real engineering.

Process Evolution

The POC often introduces small process steps such as:

  • Lightweight code reviews

  • A temporary branch in the repository

  • Simple build scripts to allow teammates to run the demonstration

This is still not production engineering. CI/CD pipelines and test automation usually come only at the MVP stage.

Backend Example

Suppose the team is building a new recommendation engine.
The backend POC might implement a single endpoint that forwards a request to an external ML service and measures latency and response quality.
Logging might be minimal, validation might be non-existent, and error handling might be crude—but the team learns whether the external ML service meets the performance requirements.

Frontend Example

A frontend POC might involve building a rough React component that displays personalized recommendations using mock data.
The component may not follow the design system, may not handle loading states cleanly, and may ignore error cases.
The goal is to check whether the UI interaction model feels intuitive and whether the state updates behave as expected.

Security

Security engineers examine how the POC handles sensitive data, even if the handling is mocked.
They validate risky paths such as authentication flows, data transformation logic, or external integrations.
The POC must identify whether the solution will require additional compliance measures, encrypted storage, or stricter authentication schemes.
This becomes a mandatory input for the MVP.

The post From Idea to Proof of Concept to MVP: The POC stage (2/3) first appeared on Sorin Mustaca’s blog.

From Idea to Proof of Concept to MVP: The Idea stage (1/3)

/in

This is a a developer focused guide in three parts to evolving code, architecture, and processes with the purpose of turning a raw concept into a usable product. This process is one of the hardest parts of software development.

Teams often jump into implementation too early, or they build something polished before testing whether the underlying assumptions hold.

A structured flow—Idea → Proof of Concept (POC) → Minimum Viable Product (MVP)—keeps this journey predictable and reduces waste.

Each stage exists for a specific reason, and each stage demands a different mindset about code quality, design rigor, and security.
For developers, this is also a shift in how code is written, reused, refactored, and prepared for production.
This article explains the journey from the perspective of engineering teams, with practical backend and frontend examples and a clear separation of security activities.

Legend

Idea
A raw concept describing a problem and a possible technical direction. It has no validated assumptions.

At this point, teams focus on understanding why the problem matters and what a potential solution could look like. No production-ready code exists yet.

Proof of Concept (POC)
A disposable implementation created to validate one or two critical assumptions. The focus is feasibility, not quality.

The POC answers narrow engineering questions such as: Can this API be used to implement the idea? or Can the frontend render this interaction reliably?

Code is expected to be thrown away or heavily rewritten later.

Minimum Viable Product (MVP)
A functional, small-scope product that solves a real user need with the minimum set of features.

Unlike a POC, the MVP requires maintainable code, basic architecture, observability, initial security measures, and repeatable engineering processes.

It is the first version that can be deployed and measured with real users.

Transition: Idea → POC
The transition tests feasibility. Only the highest-risk technical assumptions are validated. Success means the idea has enough technical grounding to justify investment.

Transition: POC → MVP
The transition focuses on turning validated feasibility into a real product. Teams refactor or rebuild the POC code into production-ready components. Architecture stabilizes, security controls appear, and processes become repeatable.

1. The Idea Stage

The idea stage is where the team defines the problem and shapes the first version of the solution direction. The discussion is broad, and uncertainty is still high.

At this point the team is not writing code in any meaningful sense, but rather exploring possibilities, boundaries (technological, legal, usability related), and early risks.

The goal here is not to “design the whole system”. The goal is to understand whether the idea is worth testing and whether the technical foundation appears feasible. This prevents teams from sinking time into something that cannot work or is not worth the investment.

What Makes This Stage Unique

The idea stage is low-cost, low-risk, and exploratory. Developers participate mainly by assessing feasibility, identifying potential architectural constraints, and sketching which components might be reused later. The conversation stays intentionally shallow. Nothing should be implemented that the team cannot abandon without regret.

Inputs and Outputs

Inputs include the product need, early UX sketches, discussions about the problem, and high-level constraints such as data privacy, integration requirements, or performance expectations.
Outputs include a defined problem statement, a preliminary solution outline, and a clear hypothesis that the POC must validate.

Actors

Product managers frame the problem. Engineering leads assess feasibility. UX designers shape initial user interactions. Security architects provide early warnings about potential data-handling or compliance pitfalls.

Engineering Expectations at This Stage

Code and Architecture

No production code is written. If developers create anything, it is lightweight and disposable:
simple mock APIs written in Postman collections, small HTML/JS mockups, or rough OpenAPI drafts.
Nothing created at this stage is meant to be reused directly, but these drafts help teams align on concepts.

However, developers should already think about potential reuse paths.
For instance, if the solution will likely need a shared data-access layer or a reusable front-end state-management module, this is the time to name those opportunities—even if nothing is implemented.

Process Implications

The team documents assumptions, potential dependencies, and cases where reuse might save time later.
There is no review process, no CI pipeline changes, and no branching strategy decisions.
This remains a design and exploration stage.

Backend Example

A backend developer might sketch a future architecture in AWS or draft a sequence diagram showing how the system would communicate with an external payment service.
They might explore the integration constraints by reading documentation and checking rate limits, but no or very little code is produced.

Frontend Example

A frontend developer might draft wireframes and map out how new UI states could fit into existing structures.
They might also check whether existing UI components can be repurposed to avoid re-inventing layout patterns later.

Security and Privacy

Security work is limited to conceptual analysis. No real data is supposed to be used in this stage, so privacy concerns should not exist.
Security architects identify which data categories will be processed, assess whether regulatory frameworks apply, and highlight technical constraints that must be tested in the POC.
No security implementation takes place at this stage, but early awareness helps avoid blind spots later.

The post From Idea to Proof of Concept to MVP: The Idea stage (1/3) first appeared on Sorin Mustaca’s blog.

Delivering often in small increments with Scrum

/in

Agile software development, particularly using Scrum, has revolutionized the way software is built and delivered.

At its core, Agile embraces iterative and incremental development, a stark contrast to traditional “waterfall” methodologies.

The primary objective is to deliver working software frequently and in small increments, ensuring continuous feedback, adaptability, and rapid value delivery.

However, we know from experience that this is not always the case, and if you have worked long enough in the software development industry, you know that usually, it is not the case.

I wrote before about this and the articles were well read (on LinkedIn), but I still see the need to summarize those articles:

Guide for delivering frequently software features that matter (series) #1/2: the Pillars of successful frequent delivery

Guide for delivering frequently software features that matter (series) #2/2: Challenges and the path forward

 

Key principles and practices

In order to frequently deliver small-increment you need to implement several key principles and practices:

Decomposition and User Stories

Break down large features or requirements into smaller, manageable user stories.
A well-formed user story describes a desired functionality from the perspective of an end-user, following the format: “As a [type of user], I want [some goal] so that [some reason].”
These stories are then estimated and prioritized.

Time-boxed Sprints

Scrum operates in short, fixed-length iterations called “sprints,” typically 2-4 weeks long.
Each sprint has a specific goal and a defined set of user stories to be completed.
The time-box ensures a consistent rhythm of delivery and prevents scope creep within an iteration.

Definition of Done (DoD)

A clear and shared “Definition of Done” is crucial.
This defines the criteria that a user story must meet to be considered complete, including coding, testing, documentation, and integration.
This ensures quality and prevents partially finished work from accumulating.

 

Cross-functional Teams

Scrum teams are self-organizing and cross-functional, meaning they possess all the skills necessary to take a user story from conception to delivery.
This reduces dependencies and streamlines the development process.

 

Frequent Feedback Loops

Scrum incorporates several built-in feedback loops:

  • Daily Scrums: Short daily meetings where the team synchronizes, discusses progress, and identifies impediments.
  • Sprint Demo: At the end of each sprint, the team demonstrates the “potentially shippable increment” to stakeholders, gathering feedback for future sprints.
  • Sprint Retrospectives: The team reflects on the past sprint to identify what went well, what could be improved, and creates actionable plans for the next sprint.

Prioritization and Backlog Refinement

The Product Owner is responsible for maintaining and prioritizing the Product Backlog, a living list of all desired features.
Regular “backlog refinement” sessions ensure that upcoming user stories are well-understood, estimated, and ready for development.

 

Now, if you think that by doing this solves all your problems, well, you are not entirely wrong, but also not entirely right. 🙂

As with any methodology, there are challenges.

Challenges and Solutions

Large, Undifferentiated Requirements

Stakeholders often present high-level, monolithic requirements that are difficult to break down into small, shippable increments. This can lead to long development cycles and delayed feedback.

Solutions

  • Invest in User Story Mapping: Collaboratively map out the user’s journey and identify smaller, deliverable “slices” of functionality.
  • Employ techniques like “Splitting User Stories”: Learn patterns and techniques to effectively break down large stories into smaller, valuable pieces (e.g., by workflow steps, by data type, by role).
  • Product Owner Focus: The Product Owner plays a critical role in collaborating with stakeholders to refine and decompose requirements, ensuring they are “INVEST” (Independent, Negotiable, Valuable, Estimable, Small, Testable)

Technical Debt and Integration Issues

Rapid delivery can sometimes lead to accumulating technical debt (shortcuts taken for speed) and integration headaches if not managed carefully.

This can slow down future development and make small increments harder to achieve.

Solutions

  • Prioritize Technical Excellence: Bake in time for refactoring, code quality, and automated testing within each sprint. The Definition of Done should include these aspects.
  • Continuous Integration and Continuous Delivery (CI/CD): Implement robust CI/CD pipelines to automate builds, tests, and deployments, ensuring that the software is always in a releasable state.
  • Pair Programming and Code Reviews: collaborative development and peer review usually catch issues early and maintain code quality, but they also slow down delivery. Use with care.

Lack of Clear Prioritization

Without a clear and stable Product Backlog and a Product Owner empowered to make decisions, teams can struggle with shifting priorities, leading to wasted effort and delayed delivery.

Solutions

  • Empower the Product Owner: Ensure the Product Owner has the authority and understanding to prioritize the Product Backlog effectively, balancing business value, risk, and dependencies.
  • Regular Backlog Refinement: Conduct frequent and collaborative backlog refinement sessions to ensure upcoming stories are well-understood and ready for development.
  • Transparency: Make the Product Backlog visible and accessible to everyone, fostering understanding and aligning expectations.

 

External Dependencies and Silos

In larger organizations, external dependencies (e.g., other teams, external vendors, compliance departments) or internal silos can hinder a team’s ability to deliver independently and frequently.

Solutions

  • Active Stakeholder Management: The Product Owner and Scrum Master should proactively identify and manage external dependencies, facilitating communication and coordination.
  • Cross-team Collaboration: Encourage regular communication and collaboration between teams, potentially through “Scrum of Scrums” or other scaling frameworks if applicable.
  • Shift to a “Value Stream” Mindset: Focus on optimizing the flow of value across the entire organization, identifying and removing bottlenecks that span multiple teams or departments.

The post Delivering often in small increments with Scrum first appeared on Sorin Mustaca’s blog.

Accelerating feature delivery in software development

/in

My company develops security products for all major operating systems. We work with startups and with big companies, all striving to develop features (functional and non-functional) as fast and as good as possible.

While on the first view this seems like a contradiction, there are actually ways of implementing exactly this.

For security software development teams aiming to deliver features more frequently, streamlined processes and efficient workflows are essential.

You guessed, the keywords are agile methods with the related activities such as automated testing, strategic prioritization, agile delivery, efficient workflows, regular and early feedback.

Below are several approaches that emphasize frequent and reliable delivery.

Define requirements with speed in mind

Clear, concise requirements set a strong foundation for quick delivery. Ensuring each feature has straightforward objectives and well-defined acceptance criteria reduces delays caused by back-and-forth clarifications. For security-focused teams, requirements should include key security considerations without overloading the development process. By clarifying expectations from the start, developers can stay on track, avoiding unnecessary revisions and accelerating overall delivery. This being said, also do not change the direction too often (called Pivoting). If you don’t allow feature to “sit”, the product will never reach maturity.

Setup incremental, agile delivery

Breaking down feature development into small, manageable increments supports faster delivery. Rather than waiting for a full release, an incremental approach allows developers to deliver small updates frequently. This Agile-inspired method brings quick wins, shortens feedback cycles, and lets teams adjust direction as needed based on real-world usage. Incremental delivery ensures that new functionality reaches users sooner, making the product more responsive to changing needs.

Optimize for efficiency

Security doesn’t have to slow down delivery. By embedding secure coding practices into the team’s daily workflows, developers can build security right into each feature rather than adding it at the end. Code reviews focused on security can be streamlined with checklists or automated tools, keeping the process efficient. This “security-first” mindset ensures that features remain secure while minimizing delays, as there’s no need for last-minute security fixes.

Invest in CI/CD

Automated testing is key to quick, reliable feature deployment. Automated tests that cover basic functionality and security requirements provide instant feedback, allowing developers to identify and address issues faster. Implementing continuous integration (CI) tools that automatically trigger these tests during development helps the team validate new features on the go. By automating tests, the team gains more time for development and can release updates with minimal manual intervention.

Integrating DevSecOps practices into the development pipeline enables seamless security without slowing down delivery. Automated security checks within the CI/CD pipeline provide fast, reliable security validations, allowing developers to address issues before deployment. This approach keeps the pipeline moving smoothly, as security checks become an integrated part of the process, rather than an additional step that slows down delivery.

Encourage collaborative and efficient workflow

Encourage open communication between developers, security teams, and testers to streamline workflows. Collaborative sessions for discussing roadblocks or coordinating on shared goals help prevent bottlenecks. An open environment where team members share updates and resolve issues collectively accelerates progress by addressing concerns in real time. By emphasizing collaboration, teams can work faster, catching potential blockers early and adapting quickly to new requirements.

Use regular retrospectives to identify and remove delivery obstacles

Post-release retrospectives focused on delivery efficiency help identify and eliminate roadblocks. By analyzing each release or sprint for delays and other issues, teams can identify specific pain points in the development or deployment process. These retrospective sessions allow the team to adjust practices and improve their ability to deliver quickly, refining the workflow with each iteration.

 

The post Accelerating feature delivery in software development first appeared on Sorin Mustaca on Cybersecurity.

Understanding the SOC 2 Certification

/in

Introduction

SOC 2 (Service Organization Control 2) certification is a framework designed by the American Institute of CPAs (AICPA) to help organizations manage customer data based on five Trust Service Criteria: , confidentiality,processing integrity, availability, security and privacy. This certification is crucial for service organizations that store or process customer data in the cloud.

Comparison of Various SOC Certification Versions

SOC 1 (Service Organization Control 1)

  • Focus: SOC 1 is centered around internal control over financial reporting. It is particularly relevant for service organizations that impact their clients’ financial statements.
  • Users: Primarily used by financial auditors and companies that outsource services impacting financial operations.
  • Types: There are two types of SOC 1 reports:
    • Type I: Assesses the suitability of the design of controls at a specific point in time.
    • Type II: Examines the effectiveness of controls over a defined period.

SOC 2 (Service Organization Control 2)

  • Focus: SOC 2 addresses controls relevant to security, availability, processing integrity, confidentiality, or privacy, based on the AICPA’s Trust Services Criteria.
  • Users: Useful for management, customers, regulators, and other stakeholders concerned with information security and privacy.
  • Types: Like SOC 1, SOC 2 also offers Type I and Type II reports, focusing either on the design of controls at a point in time or their effectiveness over time.

Note: There is also SOC 3, but it is out of scope of this article.

 

Who Should Certify?

SOC 2 certification is essential for any organization that handles customer data, particularly cloud service providers, SaaS companies, and data centers.

It’s also relevant for companies in healthcare, finance, and other sectors where data security is paramount.

Why Certify?

Organizations pursue SOC 2 certification to demonstrate their commitment to data security, build customer trust, and comply with industry regulations. It also helps them stand out in competitive markets and avoid the financial and reputational damage associated with data breaches.

What Is Certified?

SOC 2 certification verifies that an organization adheres to robust information security policies and procedures. The certification evaluates five trust service criteria:

  1. Security: Protection of system resources against unauthorized access.
  2. Availability: Accessibility of the system as agreed upon.
  3. Processing Integrity: System processing is complete, valid, accurate, timely, and authorized.
  4. Confidentiality: Protection of confidential information.
  5. Privacy: Collection, use, retention, and disposal of personal information is in line with the organization’s privacy notice.

While some security frameworks like ISO 27001, PCI DSS, TISAX, HIPAA  have rigid requirements, SOC 2 considers that controls are unique to every organization.

Each company designs its own controls to comply with its Trust Services Criteria.

An independent auditor is then brought in to verify whether the company’s controls satisfy SOC 2 requirements.

After the audit, the auditor writes a report about how well the company’s systems and processes comply with SOC 2.

Every organization that completes a SOC 2 audit receives a report, regardless of whether they passed the audit.

There are two types of SOC 2 reports:

  • SOC 2 Type I reports evaluate a company’s controls at a single point in time. It answers the question: are the security controls designed properly?
  • SOC 2 Type II reports assess how those controls function over a period of time, generally 3-12 months. It answers the question: do the security controls a company has in place function as intended?

To choose between the two, consider your goals, cost, and timeline constraints.

A Type I report can be faster to achieve, but a Type II report offers greater assurance to your customers.

 

 

Topics Verified in SOC 2 Certification

1. Security

The Security Criteria are also known as the Common Criteria. They prove that a service organization’s systems and control environment are protected against unauthorized access and other risks.

Security is the only Trust Services Criteria required for every SOC 2 audit. The other criteria can be added to your report scope if your organization chooses, but they are not required to achieve SOC 2 compliance.

These are the security criteria needed for SOC 2:

  • CC1 — Control environment
    Does the organization value integrity and security?
  • CC2 — Communication and Information
    Are policies and procedures in place to ensure security? Are they communicated well to both internal and external partners?
  • CC3 — Risk Assessment
    Does the organization analyze risk and monitor how changes impact that risk?
  • CC4 — Monitoring Controls
    Does the organization monitor, evaluate, and communicate the effectiveness of its controls?
  • CC5 — Control Activities
    Are the proper controls, processes, and technologies in place to reduce risk?
  • CC6 – Logical and Physical Access Controls
    Does the organization encrypt data? Does it control who can access data and restrict physical access to servers?
  • CC7 – System Operations
    Are systems monitored to ensure they function properly? Are incident response and disaster recovery plans in place?
  • CC8 – Change Management
    Are material changes to systems properly tested and approved beforehand?
  • CC9 – Risk Mitigation
    Does the organization mitigate risk through proper business processes and vendor management?

Implementation: Organizations must establish and maintain a set of security controls to protect against unauthorized access. This includes firewalls, encryption, access controls, and intrusion detection systems.

Audit: Auditors examine security policies, test the effectiveness of security controls, and review incident response plans.

Responsibility: Chief Information Security Officers (CISOs) and IT security teams are typically responsible for implementing and maintaining these controls.

2. Availability

Implementation: Ensuring systems are available involves implementing redundancy, disaster recovery plans, and maintaining system performance monitoring.

Audit: Auditors assess the organization’s ability to meet service level agreements (SLAs) and review backup and recovery procedures.

Responsibility: IT operations teams and service managers oversee availability aspects.

3. Processing Integrity

Implementation: Organizations must ensure that data processing is accurate and complete. This includes validating input data, processing logic, and output accuracy.

Audit: Auditors review data processing controls, check for errors, and validate processing integrity.

Responsibility: Data quality teams and IT personnel are responsible for maintaining processing integrity.

4. Confidentiality

Implementation: Protecting confidential information involves data encryption, access controls, and secure storage solutions.

Audit: Auditors evaluate the measures in place to protect confidential data and check compliance with confidentiality agreements.

Responsibility: Data protection officers (DPOs) and compliance teams handle confidentiality matters.

5. Privacy

Implementation: Organizations must adhere to privacy policies that govern the collection, use, and disposal of personal data. This involves data anonymization and consent management.

Audit: Auditors examine privacy policies, consent forms, and data handling procedures to ensure compliance with relevant privacy laws.

Responsibility: Privacy officers and legal teams are responsible for privacy compliance.

Conclusion

SOC 2 certification is a comprehensive framework that ensures organizations adhere to best practices in data security and management.

By certifying under SOC 2, organizations can demonstrate their commitment to protecting customer data, comply with regulatory requirements, and gain a competitive edge in the market.

Implementing and maintaining SOC 2 controls requires collaboration across various teams, including IT, security, operations, and legal departments, to ensure continuous compliance and security.

The post Understanding the SOC 2 Certification first appeared on Sorin Mustaca on Cybersecurity.