Posts

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.

Maping NIS2 requirements to the ISO 27001:2022 framework

/in

We described here the process needed to perform a gap analysis for NIS2, but we did not add the details on how to approach this.

This article references on the ISO27001:2022 series, especially on the description of the Annex A controls. Make sure you are familiar with the ISO 27oo1:2022 requirements and the with the Annex A.

Introduction

The NIS2 Directive, aimed at strengthening network and information system security across the European Union, necessitates a thorough alignment with the latest iteration of the ISO 27001 standard, which was updated in 2022. This article explores a comprehensive methodology for conducting a gap analysis to ensure compliance with NIS2 using the framework provided by ISO 27001:2022.

Understand NIS2 Requirements

The NIS2 Directive expands upon its predecessor by setting stringent cybersecurity and resilience measures for essential and important entities across various sectors. Its key focus areas include incident response, supply chain security, and the security of network and information systems. These areas are critical in maintaining the integrity and availability of services that are vital to the internal market and public welfare.

 

The NIS2 Directive does not prescribe a specific set of controls for the affected companies.

Rather, it states that they should adopt measures that are appropriate to their specific risk profile, considering factors such as:

  • The state of the art in cybersecurity

  • The potential impact of incidents on their services

  • The costs of implementing the measures

  • The proportionality between the measures and the risks

The directive also refers to existing standards, guidelines, and best practices that can help entities to choose suitable controls.
For example, it mentions:

  • The NIST Cybersecurity Framework

  • The ENISA Good Practices for Security of Internet of Things

  • The ETSI Technical Specification on Critical Security Controls for Effective Cyber Defense

 

Read here our collection of articles about the NIS2 directive.

Overview of ISO 27001:2022

ISO 27001:2022 establishes requirements for an Information Security Management System (ISMS), providing a systematic approach to managing sensitive company information so that it remains secure.

It includes people, processes, and IT systems by applying a risk management process and clearly defines information security control requirements in its Annex A .

 

Similarities

Despite the differences in scope, objectives, requirements and controls, there are some similarities between the NIS2 Directive and the ISO 27001:2022 standard.

Here are the most evident similarities :

  • Risk management: Both frameworks are based on the concept of risk management, which involves identifying, analyzing, evaluating, and treating the information security risks that affect the organization or the service.

  • Involvement and commitment of top management: Both frameworks require the involvement and commitment of top management, who are responsible for ensuring that the appropriate resources, roles and responsibilities are allocated to support the implementation and maintenance of the measures.

  • Importance of continuous improvement: Both frameworks emphasize the importance of continuous improvement, which involves monitoring, measuring, reviewing, and updating the measures to ensure they remain effective and relevant in a changing environment.

  • Cooperation and information sharing: Both frameworks encourage cooperation and information sharing among relevant stakeholders, such as authorities, regulators, customers, suppliers, and peers, to enhance the overall level of cybersecurity.

Mapping NIS2 to ISO27001:2022 requirements

The mapping begins with identifying the specific NIS2 requirements that are applicable to the organization.

Step 1: Identify NIS2 requirements

1. Scope of Application

  • Expansion of Affected Entities: NIS2 extends its requirements beyond the sectors covered by the original NIS Directive, including essential and important entities across various sectors such as energy, transport, health, and digital services.

2. Risk Management Measures

  • Comprehensive Security Requirements: Entities are required to implement appropriate technical and organizational measures to manage the risks posed to the security of network and information systems, including measures for incident handling, business continuity, and supply chain security.

3. Incident Response and Reporting

  • Incident Reporting Obligations: NIS2 mandates strict incident reporting requirements, where entities must notify relevant national authorities about significant cybersecurity incidents with potentially severe operational impacts, within a short timeframe.

4. Supply Chain Security

  • Security of Supply Chains and Supplier Relationships: Entities need to address cybersecurity risks not only within their own operations but also across their supply chains, ensuring that suppliers meet security requirements to protect against potential vulnerabilities and threats.

5. Interoperability and Cooperation

  • Enhanced Cooperation Among States: NIS2 emphasizes improved information sharing and coordinated response among EU member states, with mechanisms for cross-border collaboration in cybersecurity threat detection, response, and recovery.

6. Security and Network Systems

  • Strengthening of Security Practices: Detailed requirements on securing network and information systems, ensuring the integrity, availability, and confidentiality of services, particularly in critical infrastructure sectors.

7. Regulatory Oversight and Compliance

  • Increased Enforcement Powers: Regulatory authorities are granted more significant powers to enforce the Directive, including the ability to conduct audits, review compliance, and impose sanctions on entities failing to meet the cybersecurity requirements.

8. Financial Penalties

  • Penalties for Non-Compliance: NIS2 introduces substantial financial penalties for non-compliance, aimed at ensuring that entities take their cybersecurity obligations seriously.

9. Cybersecurity Measures Specificity

  • Detailed Guidelines and Standards: The Directive encourages the use of established standards and specifications to fulfill the required security measures, promoting best practices in cybersecurity management.

 

This step involves a detailed review of NIS2, focusing on the obligations that directly impact the organizational processes and security measures.

Step 2: Map requirements to the ISO 27001:2022 chapters

The next step is to map relevant chapters and controls in ISO 27001:2022 to these NIS2 requirements:

  • Chapter 4 (Context of the Organization) -> NIS2 1,4,5
    • Understand external and internal issues that affect the ISMS, aligning with NIS2’s broader security requirements.
    • Identify if the company is falling into the two entity categories: Important and Essential.
    • An important step is also to identify and assess all external suppliers.
  • Chapter 5 (Leadership) -> NIS2 1,5,8
    • Ensures management’s commitment to the ISMS, mirroring NIS2’s emphasis on leadership and governance in cybersecurity.
  • Chapter 6 (Planning) -> NIS2 2,3,4,6 
    • Address the assessment and treatment of information security risks, a core component of proactive compliance under NIS2.
    • Conduct a risk assessment to identify threats, vulnerabilities, and impacts on information assets.
    • Develop a risk treatment plans to address identified risks, including mitigation, transfer, or acceptance.
  • Chapter 7 (Support) -> 5,7,9
    • Provide the framework for managing resources and operational planning,
    • Establish communication channels for reporting security incidents and seeking guidance on information security matters.
  • Chapter 8 (Operation) -> NIS2 2,3,4,6
    • Provide the framework for managing resources and operational planning, establishes incident response and business continuity plans to mitigate the impact of security incidents and disruptions, crucial for implementing the technical and organizational measures required by NIS2.
  • Chapter 9 (Performance Evaluation) -> NIS2 8,9
    • Assess the performance of the ISMS, helping to ensure continuous improvement in line with NIS2’s dynamic compliance landscape.

Disclaimer:
This mapping is author’s own interpretation based on his personal opinion and understanding of the requirements. It is not the only possible interpretation and it is most probably not the best one available.

 

Conclusion

By mapping NIS2 requirements to the structured framework provided by ISO 27001:2022, organizations can not only ensure compliance but also strengthen their overall security posture.

It is important to understand that this alignment is not a one-time effort but a continuous process of adaptation and improvement, reflecting the dynamic nature of cybersecurity threats and regulatory requirements.

As such, organizations should focus on regular reviews and updates to their ISMS, ensuring that it remains robust, responsive, and compliant.

The post Maping NIS2 requirements to the ISO 27001:2022 framework first appeared on Sorin Mustaca on Cybersecurity.