Posts

Introduction to the Secure SDLC in the AI-Native world: the reality check

09/09/2026/in Educational

Introduction

This is the very first article from a series of articles that will be merged with the existing SDLC Process “From Idea to Proof of Concept to MVP” previously written, finally to be rewritten in an AI-Native SDLC.

What is an “AI-Native” organization?

“AI-Native” describes an organization that has restructured how it works around AI as a default part of its processes and tooling, rather than treating AI as an add-on bolted onto existing workflows. The distinction usually drawn is between a company that uses AI tools here and there for individual tasks and one where AI is embedded into how decisions get made, how work gets planned, and how output gets produced and reviewed at a structural level. In practice this shows up as things like AI participating in planning and estimation, AI-assisted code and content generation being a normal step in production rather than an occasional shortcut, and teams and processes being redesigned so that human judgment concentrates on review, direction-setting, and accountability while repetitive execution shifts toward AI. It’s worth being clear that “AI-Native” is more of an aspirational framing used by consultants, vendors, and maturity-model frameworks than a term with one settled, universally agreed definition or an independent body of evidence behind it, so different frameworks describe the destination somewhat differently, and a company calling itself AI-Native today is making a claim about its operating model, not citing a fixed technical standard.

Where this stands right now

Adoption numbers of AI are still modest, whatever the marketing around AI-native engineering suggests. The OECD’s SME AI adoption paper, published in December 2025, puts AI use among EU enterprises with 10 or more employees at 13.5 percent in 2024, a figure that had grown 60 percent from the year before. Korea, Denmark, and Sweden lead with adoption above 25 percent, while Hungary sit under 4 percent. Small firms across the OECD median at just 8.5 percent.

The United States shows a similar order of magnitude. The Census Bureau’s Business Trends and Outlook Survey put firm-level AI adoption at roughly 18 percent by the end of 2025, with usage hovering between 17 and 20 percent through the following months. Adoption skews heavily by company size: firms with 250 or more employees report adoption near 37 percent, while businesses under 20 employees stay under 20 percent with little movement. A Federal Reserve note on the same data pointed out that different survey methods produce very different headlines. Weight the numbers by employment instead of by firm count, and the share of the US workforce at AI-adopting companies jumps to 78 percent, because large employers over-represent in the workforce count even though they’re a minority of firms.

Put those two data points side by side and the takeaway isn’t that the US is racing ahead of Europe or vice versa. Both regions sit in the 10-25% for firm-level adoption, with large enterprises far out in front and small and mid-sized companies lagging by a wide margin.

That gap matters for this study, because SSDLC practice has historically been something larger, better-resourced engineering organizations do more rigorously than smaller ones do, and AI tooling is following the same adoption curve rather than flattening it.

Human Roles vs AI in an SDLC

What the classical roles actually do in an SDLC

Before asking which roles AI might replace, it’s worth being precise about what each one is actually responsible for inside a secure development lifecycle. Job titles vary by company, but the underlying accountabilities are fairly stable across the industry.

A Developer writes the code, and in a security-conscious organization that also means threat-modeling their own change at a small scale, following secure coding standards, running static analysis and addressing what it flags, writing tests that cover both functional and abuse cases, and responding to the questions a reviewer raises. NIST’s Secure Software Development Framework treats developers as one node among several who share responsibility for producing and maintaining secure code, not as the sole owner of security outcomes.

A Team Lead sits closest to the code and closest to the people writing it. They review pull requests, arbitrate technical disagreements, make the day-to-day call on what’s good enough to ship, and translate security policy into something a five- or eight-person team can actually follow without slowing to a crawl. They’re usually the first line of defense against both bad code and unrealistic deadlines.

An Engineering Manager owns people and delivery capacity rather than any single codebase. They staff projects, set technical direction at a level above individual features, negotiate timelines with product, and are accountable when a team consistently ships insecure or unstable software, even if they never personally reviewed the offending commit. In a mature SSDLC, they’re the one who has to defend security investment against a roadmap that always wants more features faster.

A Product Manager decides what gets built and in what order, working from customer needs, market pressure, and business goals. Security enters their world as a non-functional requirement they have to weigh against features that visibly move revenue or retention. A product manager who treats security stories as optional, rather than as a normal part of the backlog, is one of the more common root causes behind software that ships insecure by default.

A Program Manager, sometimes called a technical program manager, coordinates work across multiple teams toward a shared deadline or shared dependency chain. They don’t usually write code or make product calls. Instead, they make sure the pieces from different teams land in the right order, that risks get escalated before they become incidents, and that a security requirement owned by one team doesn’t get silently dropped because it wasn’t anyone’s job to track it across a handoff.

A Designer, usually a UX or product designer rather than a graphic designer, sits between the product manager’s requirements and the developer’s implementation, translating what needs to get built into how it should actually work and look for the people using it. Their responsibilities typically span user research (interviews, usability testing, understanding actual user behavior rather than assumptions), information architecture and interaction design (how screens and flows connect, what happens on each state and edge case), producing wireframes and prototypes that get validated before code gets written, and maintaining or contributing to a design system so the product stays consistent as it grows. Designers work closely with product managers on the “what” and “why” and with developers on the “how,” often sitting in on sprint planning and reviewing implemented features against the design intent before release, which puts them in the loop earlier than testing but later than pure strategy.

For the sake or improving the readiness of this article, I skipped many roles found in companies: architect, project manager, release manager, security manager, and many more.

None of these six roles is purely technical, purely creative or purely managerial. They overlap deliberately, and the overlap is where security responsibility usually gets lost when organizations aren’t careful about defining who owns what.

Which of these roles AI can realistically take over, and why

Judged honestly, current AI systems are strongest at tasks with a narrow, well-defined scope and a fast feedback loop, and weakest at judgment calls that require weighing incomplete information against organizational politics, budget, and long-term consequences. That split maps fairly cleanly onto the six roles above.

The Developer role is where AI has made the most real inroads, and it’s not close. Code-completion and agentic coding tools can generate working code, write boilerplate tests, refactor within a defined scope, and increasingly handle small, well-scoped tickets end to end with limited supervision. This is genuine capability, not hype. It’s also bounded: these tools still perform worse on tasks that require deep familiarity with a large, idiosyncratic codebase, and they don’t carry accountability for what they produce. A junior-to-mid-level developer role focused on well-specified, repetitive implementation work is the most exposed to reduction, not elimination, because someone still has to specify the work, review it, and answer for it when it breaks in production.

The Team Lead role is only partially exposed. AI can draft a first-pass code review, flag obvious style or security issues, and summarize a pull request for a human reviewer, which measurably speeds up the mechanical parts of the job. What it can’t do is the part that actually defines the role: knowing which of two competent engineers should own a contested design decision, judging when a shortcut is acceptable given a specific deadline and a specific team’s track record, or having the difficult conversation with someone whose code quality has been slipping. That’s a role AI assists rather than replaces.

Program management is the role most vulnerable in relative terms, and this deserves more caution than the developer point, because it rests less on hard data and more on a structural observation: much of the job is tracking dependencies, chasing status updates, flagging schedule risk, and producing status reports, all tasks an AI agent with access to a company’s ticketing, calendar, and messaging systems can plausibly do today or very soon. What AI structurally cannot do is take organizational accountability. When a cross-team commitment slips and someone has to explain to leadership why, and negotiate a recovery plan that survives contact with three other teams’ competing priorities, that’s a job for a person with standing in the organization, not a tool. Companies that reduce program management headcount because of AI are, realistically, redistributing that accountability onto engineering managers rather than eliminating the need for it.

Product management and engineering management are the least exposed, and for a specific reason: both roles exist primarily to make decisions under genuine uncertainty, where the inputs are ambiguous, political, and often deliberately withheld by other parties in a negotiation. AI can synthesize customer feedback, draft specs, model trade-offs, and summarize competitive research faster than a human, all of which is useful. It cannot own the decision, and in most organizations, legally and practically, someone has to. This is also where the ownership problem discussed below becomes sharpest: a product manager or engineering manager can be held accountable in a way a model cannot, and that asymmetry alone puts a ceiling on how much of these roles gets automated regardless of how capable the underlying technology becomes.

For the Designer, applying the same standard used for the other roles, AI is currently strong at the mechanical output of design work and weak at the parts that require actually understanding a specific set of users. Generating wireframes, component variations, and even reasonably polished UI mockups from a text prompt or an existing design system is something current tools do well and quickly, tools like Figma’s AI features or Claude Design,, and similar generative design tools produce usable starting points in seconds that used to take a designer hours. Where this breaks down is user research: AI can synthesize existing feedback or summarize a pile of usability test transcripts, but it cannot observe a real user getting confused, ask a good follow-up question in an interview, or notice a behavior nobody thought to ask about, because that requires being present with actual people rather than pattern-matching against existing data. It also breaks down on judgment calls specific to a product’s actual users and actual constraints, deciding that a flow needs an extra confirmation step because your specific user base makes a specific kind of costly mistake is a decision grounded in knowledge of those people, not something a model can infer from a generic prompt.

Across all six roles, the summary is that AI is currently good at doing parts of jobs, not entire jobs, and the parts it’s worst at are consistently the parts involving accountability, ambiguity, and interpersonal judgment. Claims that any of these roles will be “replaced” in full within the next few years aren’t supported by what these systems can currently do, and predicting otherwise would be speculation dressed up as forecasting.

What it actually costs, and why the comparison is harder than it looks

A naive cost comparison between AI tools and salaried employees produces a number so lopsided it’s almost meaningless on its own, so I decided to not even write here the numbers my agent researched about both sides.

On the AI side, current subscription pricing for coding tools looks trivial by comparison. GitHub Copilot runs from $10 a month for an individual Pro seat up to $39 for Pro+ and $100 for its Max tier. Cursor’s team plan starts around $40 per user per month. Claude’s team seats run $20 to $25 a month for a standard seat and $100 to $125 for a premium seat with heavier usage. Devin, an autonomous coding agent from Cognition, is a useful case study in how unstable these numbers still are: it launched in 2024 at $500 a month per user, then cut its entry price to $20 a month with pay-as-you-go usage billing in April 2025, a 96 percent drop in list price in about a year. That volatility alone should make anyone cautious about locking a long-term staffing plan to today’s AI pricing.

Comparing a $20-to-$40-a-month subscription to a six-figure salary and concluding AI is a thousand times cheaper is the kind of number that sounds compelling and is also misleading. It compares a flat consumer subscription against fully loaded employee cost, ignoring that heavy agentic use at production scale is billed by token consumption on top of any seat fee, and that cost climbs really fast once an agent or a pod of agents are running many tasks a day against a large codebase rather than assisting one developer occasionally. It also ignores that none of these subscriptions include the human time still required to specify tasks, review output, and take responsibility for what ships, which doesn’t disappear, it shifts.

A more honest framing is that AI tooling lowers the cost of a unit of implementation work meaningfully, likely by a wide margin for well-scoped tasks, while the cost of judgment, review, and accountability stays with people and doesn’t compress at anywhere close to the same rate.

Anyone selling a straight per-seat cost comparison as the basis for a headcount decision is oversimplifying a genuinely complicated tradeoff.

If you work in or with a medium-large company, you most definitely have heard (and felt) by now that people are less production when they run out of tokens or budget for AI API. I’ve even seen people who stopped doing work entirely because their work was exclusively dependent on the AI.

The problems nobody has (fully) solved

The Ownership problem

Secure software development has always rested on a chain of accountability: someone wrote the code, someone reviewed it, someone approved the release, and if something goes wrong, that chain tells you where to look. AI-assisted development strains that chain without breaking it outright, and the strain shows up in a few concrete places.

When an AI agent generates a function that ships with a vulnerability, responsibility doesn’t transfer to the tool. It stays with whoever accepted the change, and behind them, whoever set the review standard that let it through. That’s not new in principle. Code review has always meant a human accepts responsibility for code they didn’t personally write when they approve someone else’s pull request, but the volume changes the practical reality. A reviewer who could reasonably read and understand every line from a human teammate producing a normal day’s output is in a different position when an agent can produce that same teammate’s weekly output before lunch. Review capacity hasn’t scaled at the same rate as generation capacity, and that mismatch is where accountability quietly erodes even though no one decided to lower the bar.

Regulation is starting to catch up to this gap, at least in Europe. The EU’s Cyber Resilience Act, which entered into force on December 10, 2024, with vulnerability reporting obligations starting September 2026 and full applicability by December 2027, puts security-by-design and vulnerability handling duties directly on manufacturers of products with digital elements, meaning a company, not a tool vendor and not an AI system, carries legal liability for what ships.

That’s a useful anchor for this discussion: whatever role AI plays in producing the code, the CRA and comparable frameworks assign the obligation to a legal person, which in practice means it lands on the product manager who approved the feature, the engineering manager who staffed the team, or the executive who signed off on the release process. Ownership doesn’t dissolve into the AI supply chain. It concentrates on whoever’s name is on the compliance filing.

The second ownership problem is subtler and gets less attention: origin. When a change comes from an AI agent trained on a mix of licensed, open-source, and possibly improperly sourced code, questions about IP ownership and license compliance follow the code into your repository, and most organizations don’t yet have a clean answer for how to audit that. This is a real gap, not a hypothetical one, but it’s also not the focus of this study, and claiming certainty about how it will resolve legally would be guessing.

The large-change problem

One of the more concrete, currently measurable concerns about AI-generated code doesn’t come from theory. It comes from repository analysis. GitClear’s 2025 research, based on roughly 211 million lines of changed code from 2020 through 2024, found that the share of copy-pasted code in commits rose from 8.3 percent in 2021 to 12.3 percent by 2024, a roughly fourfold increase in code cloning, and that this was the first year copy-pasted code exceeded moved (that is, refactored and reused) code as a share of changes. Over the same period, refactoring activity dropped from about 25 percent of changed lines to under 10 percent. Put plainly: AI-assisted development is correlating with more code being duplicated rather than reused, and less time spent cleaning up what’s already there.

Google’s DORA research told a related story in its 2024 State of DevOps report: AI adoption measurably increases individual developer productivity, flow, and reported job satisfaction, but it also has a negative association with software delivery stability and throughput at the team level. The report’s own conclusion is worth repeating rather than paraphrasing loosely, because it resists the instinct to treat AI as an unqualified win: teams still need small batch sizes and strong automated testing for AI adoption to pay off, and skipping those fundamentals while adding AI tends to make instability worse, not better.

This is the practical version of the large-change concern raised at the outset. A human developer fixing a bug or adding a feature typically produces a change scoped tightly to that problem, in part because writing more code by hand costs more effort, which is itself a natural brake on unnecessary changes. An AI agent doesn’t share that constraint. Left without tight instructions, it can regenerate a function instead of patching three lines, restructure a file that didn’t need restructuring, or produce a pull request that touches far more surface area than the underlying problem required.

For a normal engineering team this is mostly a productivity and maintainability issue. For a team operating under SSDLC discipline, it’s a security issue too, because every additional line of unnecessary change is additional surface a reviewer has to reason about, additional code that could introduce a new vulnerability unrelated to the original task, and additional material that pull-request-based security gates, which were designed around human-sized diffs, weren’t built to handle efficiently.

The fix isn’t rocket-science: create tightly scoped prompts, diff-size limits enforced in CI/CD, and review processes that explicitly budget more time per AI-touched line than per human-touched line. But it does mean SSDLC processes calibrated for human-paced development need deliberate recalibration, not a simple bolt-on, before AI-generated changes flow through them safely.

Viewing everything through the security lens

The first is (security) review capacity, already touched on above but worth stating as a standalone risk: if AI increases the volume of proposed changes faster than an organization can proportionally increase qualified review capacity, the SSDLC’s central control, human review before merge, degrades quietly (who can review a few hundred to a few thousand lines of code?). Tools that pre-screen pull requests for common vulnerability classes, flag deviations from secure coding standards, and cross-reference changes against known-bad patterns can catch a meaningful share of routine issues before a human ever looks at the diff. That’s a legitimate use of AI inside the SSDLC, not a replacement for review but a filter that makes human review time go further. It is not a substitute for a qualified person understanding why a change is safe, because current tools still miss business-logic flaws, subtle authorization bugs, and anything that requires understanding intent rather than pattern-matching against known vulnerability signatures.

The second is threat modeling. This has always been a weak point in real-world SSDLC practice, done thoroughly by well-resourced teams and skipped or rushed everywhere else, and AI-generated code makes the gap more costly rather than closing it. An AI agent implementing a feature has no inherent model of your system’s trust boundaries, and it will happily generate code that’s locally correct while violating an assumption three services away that it has no way of knowing about. AI can assist with threat modeling, drafting a first-pass data flow diagram or suggesting the standard threats for a common pattern like an authentication endpoint, but the exercise of defining trust boundaries for a specific system still needs someone who understands that system’s actual architecture and actual attackers, not just the generic case.

The third is dependency and supply chain risk, and here AI cuts both ways more clearly than anywhere else in this study. AI coding tools frequently pull in third-party packages to solve a problem quickly, sometimes packages the requesting developer or his organization has never evaluated, which is a direct path to the kind of software supply chain risk that frameworks like the NIST SSDF and the CRA specifically target. At the same time, AI-driven software composition analysis is one of the more mature and genuinely useful security applications available today: automated dependency scanning, license checking, and known-vulnerability matching against something like a software bill of materials are tasks AI and traditional automation both handle well, arguably better than a human doing it manually, because the problem is pattern-matching against a large, structured dataset rather than exercising judgment.

The fourth is secrets and credential handling. AI-assisted code generation has a documented tendency to reproduce patterns it’s seen in training or context, including hardcoded credentials, overly permissive default configurations, and insecure examples lifted from documentation that was never meant for production use. Automated secret-scanning in CI pipelines addresses this reasonably well and should be considered close to mandatory in any AI-assisted workflow, not optional hardening.

The fifth, and the one most directly tied to the ownership discussion above, is audit trail integrity. When responsibility for a security incident needs to be reconstructed, an organization needs to know not just what changed but who or what proposed it, who reviewed it, and on what basis it was approved. Many teams adopting AI coding tools haven’t yet updated their change-tracking to distinguish AI-authored contributions from human-authored ones in a way that would hold up under a real incident investigation or a regulatory audit under something like the CRA. This is a solvable process gap, not a technology limitation, and it’s one of the more actionable items an organization can fix regardless of how the higher-level AI adoption debate resolves.

Across all five of these, the pattern repeats: AI is a legitimately strong addition to the mechanical, pattern-matching layer of SSDLC, the parts of the process that were always partly about processing volume and consistency. It is not yet, and on current evidence shouldn’t be trusted as, a replacement for the judgment layer, the part of SSDLC that depends on someone understanding a specific system, a specific threat environment, and a specific organization’s risk tolerance well enough to make a defensible call and stand behind it.

Where this leaves the AI-Native ambition

None of this argues against AI adoption in software development, and it shouldn’t be read that way. The productivity data is real, the tooling is improving quickly, and organizations that ignore it will fall behind those that use it well. But the specific framing of AI-Native as a wholesale replacement for classical engineering roles doesn’t hold up against either the adoption data or the capability evidence available right now. Adoption is still concentrated in large firms and still sits under 20 percent even there. The roles most exposed, developer implementation work and parts of program coordination, are exposed to significant augmentation and some headcount pressure, not elimination, because the accountability those roles carry doesn’t transfer to a model no matter how capable it becomes. And the security discipline this study set out to examine gets harder in specific, nameable ways before AI makes it easier, chiefly through review capacity strain and larger, less-scoped changes, even as AI genuinely helps with the more mechanical parts of the same discipline, like dependency scanning and first-pass code review.

The realistic path for most organizations is narrower and less dramatic than either the AI-replaces-engineering narrative or the AI-changes-nothing narrative suggests: use AI to compress the mechanical, high-volume parts of secure development, keep human ownership explicit and traceable for everything that involves judgment or carries legal accountability, and treat the SSDLC controls built for human-paced change as something that needs deliberate rework, not a simple bolt-on, before they can be trusted to hold at AI-assisted speed.

Sources

OECD, “AI adoption by small and medium-sized enterprises,” December 2025. https://www.oecd.org/en/publications/2025/12/ai-adoption-by-small-and-medium-sized-enterprises_9c48eae6.html
OECD, “The AI race is on: Businesses and regions off the blocks,” February 2025. https://oecdcogito.blog/2025/02/11/the-ai-race-is-on-businesses-and-regions-off-the-blocks/
OECD, “The Adoption of Artificial Intelligence in Firms,” May 2025. https://www.oecd.org/en/publications/the-adoption-of-artificial-intelligence-in-firms_f9ef33c3-en.html
US Census Bureau, “Large Firms With at Least 20 Employees Biggest AI Users,” 2026. https://www.census.gov/library/stories/2026/05/ai-use-businesses.html
Federal Reserve, “Monitoring AI Adoption in the U.S. Economy,” April 2026. https://www.federalreserve.gov/econres/notes/feds-notes/monitoring-ai-adoption-in-the-u-s-economy-20260403.html
NIST Special Publication 800-218, Secure Software Development Framework. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf
GitClear, “AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones.” https://www.gitclear.com/ai_assistant_code_quality_2025_research
DORA, “Accelerate State of DevOps Report 2024.” https://dora.dev/research/2024/dora-report/
European Commission, “The Cyber Resilience Act – Summary of the legislative text.” https://digital-strategy.ec.europa.eu/en/policies/cra-summary
BLS / O*NET OnLine, Software Developers national wage data. https://www.onetonline.org/link/localwages/15-1252.00
Glassdoor salary data (Engineering Manager, Product Manager, Technical Program Manager, Software Engineering Team Lead, Software Engineer Germany), accessed August 2026. https://www.glassdoor.com/Salaries/
GitHub Copilot pricing. https://github.com/features/copilot/plans
Cursor pricing. https://cursor.com/pricing
Claude pricing. https://claude.com/pricing
VentureBeat, “Devin 2.0 is here: Cognition slashes price of AI software engineer to $20 per month from $500,” April 2025. https://venturebeat.com/programming-development/devin-2-0-is-here-cognition-slashes-price-of-ai-software-engineer-to-20-per-month-from-500

The post Introduction to the Secure SDLC in the AI-Native world: the reality check first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 – The Data Protection sheet explained

10/08/2026/in Educational

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.

Why SSDLC is helping shipping faster and more secure code

21/07/2026/in Educational

Software Delivered the Same Way Every Time

Before security enters the picture, SDLC exists to solve a simpler problem: making software delivery repeatable. A team that builds features ad hoc, without a defined sequence of requirements, design, coding, testing, and release, ends up with wildly inconsistent outcomes — some releases solid, others full of regressions, and no reliable way to tell in advance which kind you’re getting. A defined lifecycle turns software development from a craft that depends on who happens to be doing it into a process with predictable checkpoints: requirements are captured and reviewed before design starts, design is reviewed before coding starts, and testing has defined entry and exit criteria rather than being whatever time is left before the deadline. That structure is what makes quality reproducible — not because any single stage guarantees a good outcome, but because catching a problem at the design review is far cheaper than catching it after three sprints of code have been built on top of a bad assumption.

Bringing Security Into That Same Structure

Secure SDLC takes that same reasoning and applies it to security specifically: if reproducible quality comes from catching problems early, in the exact stage where they’re cheapest to fix, then reproducible security should come from the same discipline, rather than from a scan run the week before release.

So, the strongest argument for SSDLC is cost (but definitely not the only one !) , which can be of multiple types — the well-established pattern across the industry is that a vulnerability caught during design or code review costs a fraction of what it costs to fix once it’s in production, and a fraction of that again once it’s been exploited and triggers an incident response.

That’s why Secure Software Development Lifecycle (SSDLC) shouldn’t be a separate track that runs alongside development — it is development, done with the assumption that someone will eventually try to break what you build. Teams that treat security as a gate before release end up with the worst of both worlds: slower delivery and no real reduction in vulnerabilities, because the flaws were baked in during design and coding, long before any scanner or pen tester got a look at the code. SSDLC works by moving that attention earlier, into requirements, architecture, and the daily habits of developers, rather than bolting it on at the end.

The practical starting point is threat modeling at the design stage, before a line of code is written. This doesn’t need to be an elaborate exercise — even a lightweight session asking what could go wrong with this feature and who would want to exploit it catches a surprising share of the issues that would otherwise surface as CVEs a year later.

From there, secure coding standards and mandatory code review with a security focus matter more than any single tool, because most real-world vulnerabilities come from ordinary logic errors: missing authorization checks, trusting client-side input, mishandling secrets.

Static analysis and dependency scanning are useful, but they catch a narrower slice of problems than people expect, and treating them as the whole strategy is a common and costly mistake.

Where I’ve seen SSDLC actually stick in an organization is when it’s expressed through Security User Stories rather than a separate compliance checklist.

A story as simple as “As an attacker, I should not be able to access another user’s data by changing the ID in the URL” gives developers something concrete to build and test against, and it fits naturally into existing sprint planning instead of competing with it. Thinks that this by default and nobody would ever do something like that in their code? You are wrong. Many developers are working under pressure to deliver quickly, don’t use AI and are sometimes unexperienced. They cut corners. Always…

This also matters for CRA and NIS2 compliance, both of which increasingly expect documented evidence that security was considered throughout the lifecycle, not just verified at the end. Framing security work as user stories creates that evidence trail almost as a byproduct of normal delivery, which is a much easier sell to engineering teams than a parallel security process they resent.

One honest caveat: SSDLC adds real overhead to the early stages of a project, and for a small team under deadline pressure that tradeoff can feel expensive in the moment.

The payoff shows up later, in fewer emergency patches and audit findings — but I’d flag that as a claim based on typical outcomes I’ve seen in consulting engagements, not something I can quantify precisely for every organization.

The post Why SSDLC is helping shipping faster and more secure code first appeared on Sorin Mustaca – Security & Technology.

Security User Stories How-To – for product managers and developers

11/07/2026/in Educational

I wrote some time ago about “How to create security user stories” and I received in the meanwhile a lot of good feedback and questions about it.

For these reasons, I decided that it is time to write again on the topic, this time with focus on two importat groups in any software developer team: Product Managers and software developers.

What a Security User Story actually is and why it needs modification for security

A regular user story captures what a user wants to do and why, following the format:

As a [role], I want [goal], so that [benefit].

A security user story does the same thing, but the “role” is often a threat actor, a security control, or a compliance requirement — and the “benefit” is about preventing harm rather than enabling convenience. Most teams write functional stories and then bolt security on at the end as a checklist. That approach fails because security requirements that arrive late in a sprint get trimmed, deferred, or implemented incorrectly because nobody thought about them during design.

The correct mental model is this: security stories live in the same backlog as functional stories, they get estimated, they get accepted or rejected based on clear criteria, and they block a release when they aren’t done. They are not a separate audit artifact. They are not a penetration test report reworded as tickets. They are engineering requirements written with enough precision that a developer can implement them and a tester can verify them without reading anyone’s mind.

For security work, the format above breaks down quickly because it was designed for positive outcomes — a user wanting access to something. Security stories often describe preventing something, enforcing a constraint, or ensuring a system behaves correctly under adversarial conditions.

A more useful format for security stories adds a threat context and a verification condition:

As a [role or attacker], I want [action or capability] so that [outcome] — therefore the system must [control] which can be verified by [test condition].

The verification condition is what separates a useful security story from a wish. If you cannot write a concrete test that passes or fails, the story is not ready to be worked on.

What Product Managers are responsible for

The product manager’s job is not to write the technical implementation details. It is to make security requirements visible, prioritized, and connected to real risk. PMs tend to treat security as either non-negotiable compliance overhead or as something the security team handles separately. Both attitudes produce bad outcomes.

In the “Ideal world”

The PM writes the threat context. This means thinking like an attacker long enough to articulate what someone with bad intentions could do with the feature being built. A PM building a file upload feature should be asking: who uploads files, what happens to those files after upload, and what is the worst realistic thing that happens if an attacker controls the file content. That thinking produces a security story. The absence of that thinking produces a feature with a file upload vulnerability discovered six months later.

PMs also own prioritization. A security story that prevents account takeover ranks higher than one that adds a password complexity rule nobody will read. That judgment requires understanding the actual risk exposure of the product, which means PMs need enough security literacy to have the conversation with their security team rather than outsourcing the entire decision.

But this is just “ideal” – which means it almost never happens. Or, at least, I have never seen this done in 25 years of product management.

In the “real world”

The PM doesn’t care about security. For the PM, it is by default assumed that the technical team will implement the feature secure by design, by default and by deployment.

This “not my concern” attitude creates a lot of friction in the development teams.

So, then, who creates the security user story?

What Developers Are Responsible For

The developer’s job is to take a security story and implement the control correctly, then write the acceptance criteria into an automated test. Developers often receive vague security requirements — “ensure input is validated” or “use secure coding practices” — and have no way to know whether their implementation is correct because the requirement has no measurable outcome.

When a developer receives a well-formed security story, the implementation work splits into two parts. First, the technical control: how does the code actually enforce what the story requires. Second, the negative test: does the code fail correctly when the control is bypassed or when an attacker sends unexpected input?

Developers should be writing both happy-path and adversarial tests for security stories. If the story says “the system must reject file uploads where the MIME type does not match the file extension,” the developer writes a test that sends a PHP file renamed as a JPEG and confirms the server returns a 40x code. That test becomes a regression guard. It will catch the next person who refactors the upload handler and accidentally removes the validation.

Example developer-implemented security story with acceptance criteria:

As a developer implementing the password reset flow, I need to ensure the reset token cannot be guessed or reused so that an attacker who intercepts or brute-forces the URL cannot take over an account.

Acceptance criteria written by the developer before coding begins: the reset token must be generated using a cryptographically secure random function producing at least 128 bits of entropy. The token must be stored as a bcrypt hash, not plaintext. The token must expire 15 minutes after generation. The token must be invalidated immediately after it is used once. A request with a token that was already used must return a 400 with no indication of whether the token was valid. These criteria become the test suite, not the documentation.

Hard, isn’t it? A lot of knowledge is required about crypto, OAuth2, etc.

Can developers do this?

How to implement this in practice

The first step is adding a threat modeling checkpoint to the definition of done (DoD) or at least in the checklists for development phases. Before a story moves into a sprint, the team asks: does this story touch authentication, authorization, data storage, external input, or external communication? If yes, a corresponding security story must exist in the backlog before the functional story is pulled in.

The second step is building a library of security story templates for common patterns. You don’t need to invent this library, there are plenty of resources available online.

Start from the common frameworks like OWASP, STRIDE, NIST, etc:

SQL injection prevention,
CSRF protection,
secure file handling,
secrets management, and rate limiting
how are Confidentiality, Integrity, Availability (CIA) affected at various stages, with different types of data

all appear repeatedly across features. A template gives the team a starting point rather than expecting developers and PMs to derive the requirement from scratch every time.

The third step is treating failed security acceptance criteria the same as failed functional tests. If a security story is not done, the feature is not done. This requires management buy-in, but it is the only way to prevent the pattern where security stories accumulate in the backlog indefinitely while features ship without their corresponding controls.

The fourth step is reviewing security stories in sprint retrospectives. Not the controls themselves, but the process: were the stories specific enough to implement, did the acceptance criteria hold up during code review, did any security debt get created because the story was underspecified. That feedback loop is what makes the team better at writing them over time.

The Three Most Common Failures

The first failure is writing security stories as restrictions without context. “The system must not allow SQL injection” tells a developer nothing actionable. It does not say where the injection risk exists, which inputs are affected, or how to verify the control is working. The correct version identifies the specific input vector, the parameterization or ORM requirement, and the test that confirms raw SQL cannot be injected through that input.

The second failure is writing security stories only after a penetration test. Pen test findings are useful, but treating them as the primary source of security stories means the team is always reacting to vulnerabilities in shipped code rather than preventing them during design. Security stories belong at feature inception, not at audit time. Best is to update the templates after each set of findings, so that you don’t repeat the issues next time.

The third failure is accepting security stories with vague verification conditions. “The login must be secure” cannot be tested. “The login endpoint must lock an account for 30 minutes after 5 consecutive failed attempts, respond with a 429 on the sixth attempt, and not disclose whether the lockout is due to the account not existing or the password being wrong” can be tested. The difference between these two is the difference between a team that thinks about security and a team that actually builds it.

Instead of conclusions

So, who is expected to create the security user stories?

Usually, PMs don’t know how and don’t think it is their problem anyway.

Most developers have not beein trained into thinking offensive security. Actually, vast majority never even had a formal training in writing secure code for their platform.

I think that the answer depends on the organization size, type and focus.

Small organizations (< 50 developers) : everybody should work together, use as much as possible templates from tools and online resources.

Medium organizations (51-200 developers) : you should have dedicated people with formal training in security. It can be that they are occupying the role of PM or developer or architect. Start from the same things as small sized organizations and adapt everything for your needs, if you can.

Large organizations (200+ developers) : you should have dedicated security architect, security developers and other roles trained in secure development. You should have your own set of templates and tools to be used. Your SDLC must include mandatory security user stories.

The post Security User Stories How-To – for product managers and developers first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 5) — Information Security Sheet: Supplier Relationships, Compliance

07/07/2026/in Educational

This is the part 5 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

ISA VDA 6.0.3 (part 5) — Information Security Sheet: Supplier Relationships, Compliance

Chapter 6 — Supplier Relationships

This chapter addresses how the organization manages information security risks arising from third parties — contractors, cooperation partners, and the exchange of sensitive information with external organizations.

Note: Chapter 6 contains no separately titled subchapter. Controls run as 6.1.x.

6.1.1 — To what extent is information security ensured among contractors and cooperation partners?

All contractors and cooperation partners must be subjected to a risk assessment covering information security before engagement. Appropriate security levels must be ensured through contractual clauses. Where there are upstream contractual obligations from the organization’s own clients, those must be passed through to relevant partners. The should-level requires that contractors and cooperation partners are contractually obligated to pass information security requirements down to their own subcontractors, and that reports and documents from these partners are reviewed. For high protection needs, proof must be provided that the supplier’s information security level is adequate for the protection needs of the information being shared — for example, through a certificate, attestation, or internal audit.

Evidence includes supplier contracts containing security clauses, risk assessment records, and for high protection needs, supplier compliance evidence such as TISAX labels, ISO 27001 certificates, or audit reports.

6.1.2 — To what extent is non-disclosure regarding the exchange of information contractually agreed?

Non-disclosure requirements must be identified and fulfilled before sensitive information is passed to any external party. The people responsible for passing information must know when NDAs are required and how to apply them. NDAs must be signed before information is shared. The should-level requires NDA templates that are legally reviewed and kept current, and the NDA itself must cover the parties involved, the type and classification of information, the purpose, the validity period, and what happens upon termination or in case of unauthorized disclosure.

Evidence includes NDA templates, signed NDA records, and documentation showing awareness of NDA requirements among staff responsible for information exchange.

Chapter 7 — Compliance

This chapter addresses the organization’s obligations to comply with external legal, regulatory, and contractual requirements, and to handle personally identifiable data appropriately within its information security framework.

Note: Chapter 7 contains no separately titled subchapter. Controls run as 7.1.x.

7.1.1 — To what extent is compliance with regulatory and contractual provisions ensured?

Legal, regulatory, and contractual provisions relevant to information security must be identified at regular intervals. The landscape changes, and what was compliant last year may not be today. Policies and procedures for compliance with these provisions must be defined, implemented, and communicated to the responsible people. The should-level adds a specific focus on records integrity — the organization must ensure its records are maintained in a way that meets legal and regulatory requirements.

Evidence includes a legal and regulatory requirement register, compliance policies, communication records showing relevant staff awareness, and records management procedures.

7.1.2 — To what extent is the protection of personally identifiable data considered when implementing information security?

When personal data is processed, the legal and contractual information security requirements for that processing must be identified. Regulations for compliance with data protection requirements must be defined within the ISMS. This control is intentionally narrow in scope. It addresses data protection as an element of information security governance, not as a full replacement for GDPR compliance work (which is covered separately in the Data Protection sheet of the ISA).

Evidence includes a documented identification of applicable data protection requirements within the ISMS scope, internal policies referencing those requirements, and any relevant assessments or legal opinions obtained.

Document prepared based on ISA VDA 6.0.3, Information Security sheet. All control descriptions, requirements, and evidence expectations are derived directly from columns H (Control Question), I (Objective), J (Requirements must), K (Requirements should), L (Additional requirements for high protection needs), and M (Additional requirements for very high protection needs).

The post ISA VDA 6.0.3 (part 5) — Information Security Sheet: Supplier Relationships, Compliance first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 4) — Information Security Sheet: IT Security / Cyber Security

01/07/2026/in Educational

This is the part 4 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

ISA VDA 6.0.3 (part 4) — Information Security Sheet: IT Security / Cyber Security

Chapter 5 — IT Security / Cyber Security

This is the largest chapter in the Information Security sheet. It covers the technical and operational security measures applied to IT infrastructure, from encryption and network controls to development practices and cloud usage.

5.1 Cryptography

This subchapter addresses the use of cryptographic mechanisms to protect the confidentiality, integrity, and availability of information.

5.1.1 — To what extent is the use of cryptographic procedures managed?

All cryptographic algorithms, protocols, and key lengths used within the organization must meet recognized industry standards for their respective application. This applies across the board: encryption at rest, in transit, for signing, and for hashing. The should-level expects formal technical rules defining encryption requirements by information classification, and a cryptography concept covering algorithm choices, key strengths, key management, and the handling of lost or compromised keys. For high protection needs, key sovereignty requirements must be explicitly determined and fulfilled — particularly relevant when external services process encrypted data and the organization needs assurance that the provider cannot access keys.

Evidence includes a cryptography policy or technical standard, documentation of algorithms and key lengths used, key management procedures, and for high protection needs, documentation of key sovereignty arrangements.

5.1.2 — To what extent is information protected during transfer?

All network services used to transfer information must be identified and documented. Policies governing the use of these services must align with information classification requirements. Protection measures against unauthorized access and tampering during transfer must be implemented. The should-level adds requirements for correct addressing, content or transport encryption matched to classification, and verification that remote access connections meet adequate security standards. For high protection needs, information must be transferred in encrypted form — with documented compensating measures where encryption is not feasible. For very high protection needs, content-level encryption is required, not merely transport-level.

Evidence includes a data transfer policy, a list of approved network services, encryption configurations, and at higher protection levels, evidence of content encryption implementation.

5.2 Operations Security

This subchapter covers the day-to-day security of IT operations: managing changes, separating environments, protecting against malware, logging, handling vulnerabilities, auditing systems, managing networks, and maintaining continuity and backup capabilities.

5.2.1 — To what extent are changes managed?

Any change to the organization, business processes, or IT systems must consider information security requirements. The should-level requires a formal approval procedure for changes, impact assessments, planning and testing for changes affecting security, and documented fallback procedures. For high protection needs, compliance with security requirements must be verified both during and after change implementation.

Evidence includes a change management process, change request and approval records, testing documentation, and for high protection needs, post-implementation security verification records.

5.2.2 — To what extent are development and testing environments separated from operational environments?

Before deciding on separation, a risk assessment of IT systems must determine whether separation into development, test, and production environments is necessary. Where it is, separation must be implemented. The should-level adds more specific requirements: no development tools in production, no real production data in test environments unless appropriately protected, and documented requirements for each environment type.

Evidence includes the risk assessment that informed the separation decision, environment configuration documentation, and access control records showing restricted cross-environment access.

5.2.3 — To what extent are IT systems protected against malware?

Protection requirements against malware must be determined, and both technical and organizational measures must be defined and implemented. The should-level expects unnecessary network services to be disabled, access to remaining services to be restricted, malware protection software to be installed and automatically updated, and received files to be scanned before opening. No additional high or very high requirements apply.

Evidence includes the malware protection policy, configuration records for endpoint protection tools, and update verification records.

5.2.4 — To what extent are event logs recorded and analysed?

Information security requirements for logging must be determined and implemented. Activities of system administrators and privileged users must be logged. Systems must be assessed to determine appropriate log scope and retention. The should-level adds escalation procedures for relevant events, log integrity protection, and adequate retention periods. For high protection needs, contractual logging requirements must be met, and connections and disconnections of external networks — such as remote maintenance sessions — must be logged. For very high protection needs, any access to data of very high classification must be logged to the extent technically feasible and legally permissible.

Evidence includes a logging policy, log retention configuration, log integrity controls, and at higher protection levels, specific log samples or monitoring dashboards showing coverage of required event types.

5.2.5 — To what extent are vulnerabilities identified and addressed?

The organization must actively gather information about technical vulnerabilities affecting its IT systems — from manufacturer advisories, public CVE databases, and internal assessments — and evaluate them for relevance and severity using a structured method such as CVSS. Affected systems must be identified and remediated within an appropriate time. The should-level requires adequate patch management, including testing patches before deployment, implementing risk-minimizing measures while patches are pending, and verifying successful installation.

Evidence includes a vulnerability management procedure, subscription records for vulnerability feeds, patch management records, and evidence of CVSS-based prioritization.

5.2.6 — To what extent are IT systems and services technically checked (system and service audit)?

Technical audits of IT systems and services must be scoped, coordinated with system operators, and recorded in a traceable way. The should-level expects risk-aware planning of audits, regular execution by qualified personnel using appropriate tools, and documentation of findings and remediation. For high protection needs, critical IT systems must have additional audit requirements — such as human penetration testing or risk-driven intervals — defined and applied. For very high protection needs, IT systems and services must be regularly scanned for vulnerabilities, with documented compensating measures for systems that cannot be scanned.

Evidence includes audit planning records, audit reports, remediation tracking, and at higher protection levels, penetration test reports and scheduled scanning records.

5.2.7 — To what extent is the network of the organization managed?

Requirements for network management and segmentation must be determined and implemented. The should-level defines the basis for risk-based segmentation: limiting which IT systems can connect to the network, using appropriate security technologies, and considering performance, trust, and safety criteria. For high protection needs, additional requirements apply: IT systems must be authenticated on the network, management interfaces must be access-restricted, and specific risks — such as wireless access, remote maintenance, and IoT — must be addressed.

Evidence includes a network architecture diagram, segmentation documentation, firewall and access control configurations, and for high protection needs, network authentication records and management interface access controls.

5.2.8 — To what extent is continuity planning for IT services in place?

Critical IT services must be identified and their business impact documented. Requirements and responsibilities for continuity and recovery of those services must be known and fulfilled. The should-level expects identification of critical IT systems, appropriate classification and security measures for those systems, and planning that covers scenarios including DDoS attacks, ransomware, and power failures. For high protection needs, RTO targets must be defined in continuity plans and reflected in SLAs with external service providers. For very high protection needs, continuity plans must be coordinated with external service providers and must support continuance of essential functions with minimal or no operational interruption, including hot standby or rapid failover capabilities.

Evidence includes a business continuity and IT recovery plan, risk impact analysis, RTO and RPO documentation, SLAs with external providers, and for very high protection needs, failover test records and coordinated plans with key providers.

5.2.9 — To what extent is the backup and recovery of data and IT services ensured?

Backup concepts must exist for relevant IT systems, addressing confidentiality, integrity, and availability of backup data. Recovery concepts must also exist for relevant IT services. The should-level requires a comprehensive backup and recovery concept per IT service that accounts for inter-service dependencies and recovery sequencing. For high protection needs, backup and recovery concepts must be methodically reviewed at regular intervals, restore capability must be tested, and RPO and RTO targets must be defined. For very high protection needs, backups must be supplemented with offline procedures, immutable backups, or isolated IAM technology to protect against ransomware scenarios. Restore procedures must be technically tested at regular intervals. Geographical redundancy must be considered.

Evidence includes backup configuration documentation, recovery plans, test records proving restore capability, and for very high protection needs, immutable backup configuration records and geographically redundant storage records.

5.3 System Acquisitions, Requirement Management and Development

This subchapter covers how security is built into IT systems from the start — whether acquired from vendors or built in-house — and how the organization manages its relationships with cloud and external service providers at the technical level.

5.3.1 — To what extent is information security considered in new or further developed IT systems?

Security requirements must be embedded into both development and acquisition processes. This includes security requirements in specification documents, vendor recommendations and best practices, and fail-safe design principles. Security requirements must also be considered throughout the development lifecycle, including testing and deployment. The should-level adds formal requirement specifications referencing security standards. For very high protection needs, purpose-built or significantly customized software must undergo security testing — such as penetration testing — at commissioning, at major changes, and at regular intervals thereafter.

Evidence includes requirement specifications containing security criteria, development lifecycle documentation, and for very high protection needs, penetration test reports.

5.3.2 — To what extent are requirements for network services defined?

Information security requirements for network services must be determined and fulfilled. The should-level expects formal SLAs to document agreed requirements and adequate redundancy to be implemented. For high protection needs, traffic monitoring procedures — such as flow analyses and availability measurements — must be defined and carried out to detect anomalies and verify quality.

Evidence includes a network service requirements document, SLA agreements, and for high protection needs, traffic monitoring reports or dashboards.

5.3.3 — To what extent is the return and secure removal of information assets from external IT services regulated?

When terminating an external IT service, the organization must have a defined and implemented procedure for securely removing or retrieving its information assets. The should-level requires this procedure to be documented, kept current, and contractually embedded with the service provider.

Evidence includes a termination and data retrieval procedure, contracts containing data return and deletion clauses, and records of executed terminations.

5.3.4 — To what extent is information protected in shared external IT services?

In multi-tenant cloud or shared hosting environments, effective logical segregation must prevent other organizations’ users from accessing the organization’s information. The should-level expects the provider’s segregation concept to be documented and regularly reviewed, covering data, functions, software, operating systems, storage, and networking, as well as risk assessments for third-party software running in shared environments.

Evidence includes the cloud or hosting provider’s segregation documentation, contractual guarantees of tenant isolation, and internal review records.

The post ISA VDA 6.0.3 (part 4) — Information Security Sheet: IT Security / Cyber Security first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 3) — Information Security Sheet: Human Resources, Physical Security, Identity and Access Management

24/06/2026/in Educational

This is the part 3 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

ISA VDA 6.0.3 (part 3) — Information Security Sheet: Human Resources, Physical Security, Identity and Access Management

Chapter 2 — Human Resources

This chapter addresses the people dimension of information security: how the organization selects staff for sensitive roles, contractually binds them to security obligations, trains and raises awareness among them, and manages the risks associated with working outside the office.

Note: Chapter 2 in ISA 6.0.3 contains only one structural level beneath the chapter header. Controls are numbered in the format 2.1.x but there is no separately titled subchapter 2.1 header. The implicit grouping covers general HR security measures.

2.1.1 — To what extent is the qualification of employees for sensitive work fields ensured?

The organization must identify which roles are sensitive from an information security perspective, define the qualification requirements for those roles, and verify the identity of candidates before hiring. The should-level extends this to personal suitability checks — interviews, reference checks, or more rigorous methods depending on the role’s sensitivity. There are no additional requirements at high or very high protection need levels.

Evidence includes a list or classification of sensitive roles, defined job profiles with security-relevant criteria, and records of identity verification performed during hiring.

2.1.2 — To what extent is all staff contractually bound to comply with information security policies?

Every employee must be under a non-disclosure obligation and must be formally committed to complying with information security policies. The should-level adds an expectation that the NDA extends beyond the employment period, that security aspects are embedded in employment contracts, and that there is a procedure for handling violations.

Evidence includes employment contract templates containing NDA clauses and information security obligations, and any documented procedures for managing breaches of these obligations.

2.1.3 — To what extent is staff made aware of and trained with respect to the risks arising from the handling of information?

All employees must receive training and awareness activities related to information security. The should-level defines a minimum scope for that training: the organization’s information security policy, how to report security events, how to respond to malware, how to handle user accounts and passwords, and physical security measures. Training must be refreshed at regular intervals.

Evidence includes a training concept or awareness program, training records showing which employees completed which modules, and records of the training schedule and frequency.

2.1.4 — To what extent is mobile work regulated?

Working outside defined security zones — home offices, client sites, travel — introduces risks that must be addressed by specific requirements. The must-level requires that the organization has determined and implemented requirements covering secure access to and handling of information in both electronic and physical form during remote work. The should-level adds considerations for travel-specific risks, including measures for travel to security-sensitive countries. For high protection needs, protective measures against overhearing and visual exposure — such as privacy screens and secure communication practices — must be implemented.

Evidence includes a teleworking or remote work security policy, records showing the policy has been communicated to staff, and for high protection needs, documented technical and organizational measures against visual and acoustic compromise.

Chapter 3 — Physical Security

This chapter addresses the physical layer of information security: the security zones where information is processed, the hardware and media that carries it, and the mobile devices used to access it outside secure perimeters.

Note: Like chapter 2, chapter 3 contains no separately titled subchapter. Controls run directly as 3.1.x.

3.1.1 — To what extent are security zones managed to protect information assets?

A security zone concept must exist that maps protection requirements to physical areas — offices, server rooms, delivery zones, reception areas. The concept must define what protective measures apply in each zone, and zones must be demarcated with visible or enforced perimeters. The should-level adds expectations for access rights management procedures, visitor management policies, and rules for using mobile IT devices inside secure zones. For high protection needs, measures against overhearing and visual exposure inside or near sensitive zones must be implemented.

Evidence includes the security zone documentation, access control records, visitor logs, and for high protection needs, records of anti-eavesdropping or visual screening measures.

3.1.2 — Superseded by 1.6.3, 5.2.8, and 5.2.9

This control is no longer active in ISA 6.0.3. Its content has been redistributed into crisis management (1.6.3), IT continuity planning (5.2.8), and backup and recovery (5.2.9). No assessment is performed against 3.1.2 as a standalone control.

3.1.3 — To what extent is the handling of supporting assets managed?

Physical assets that support information processing — servers, workstations, storage media, paper — must have defined requirements covering their entire lifecycle: transport, storage, repair, loss reporting, return, and secure disposal. The should-level is not populated for this control. For high protection needs, supporting assets must be disposed of in accordance with recognized standards — for example, ISO 21964 at Security Level 4 or equivalent — to prevent data recovery from discarded equipment.

Evidence includes a hardware and media lifecycle policy, disposal records, and for high protection needs, certificates of secure destruction.

3.1.4 — To what extent is the handling of mobile IT devices and mobile data storage devices managed?

Mobile devices and removable storage must meet defined security requirements covering encryption, access protection such as PIN or password, and appropriate marking. The should-level adds device registration and user communication about risks. For high protection needs, general encryption of mobile storage devices or the information stored on them is required. Where encryption is not technically feasible, equally effective compensating measures must be implemented.

Evidence includes a mobile device management policy, encryption configuration records, device inventory, and for high protection needs, evidence of encryption enforcement or compensating controls.

Chapter 4 — Identity and Access Management

This chapter covers the mechanisms by which the organization controls who can access what — from physical identification tokens to digital user accounts and the logic for granting or revoking rights.

4.1 Identity Management

This subchapter addresses physical and digital means of identification and the authentication procedures that verify a user’s identity before granting system access.

4.1.1 — To what extent is the use of identification means managed?

Physical and digital identification tokens — keys, access cards, cryptographic tokens, certificates — must be managed across their full lifecycle: creation, issuance, return, revocation, and destruction. Validity periods must be defined and traceability maintained, along with a process for handling lost means. The should-level expects these tokens to be produced only under controlled conditions. For high protection needs, validity periods must be actively limited to an appropriate duration, and a blocking strategy for lost tokens must be both defined and implemented as far as technically possible.

Evidence includes an identification means register, lifecycle management procedures, records of issued and returned tokens, and for high protection needs, proof of validity enforcement and loss response procedures.

4.1.2 — To what extent is the user access to IT services and IT systems secured?

Authentication procedures must be chosen based on a risk assessment that considers the attack surface of each system, including whether systems are directly internet-accessible. State-of-the-art authentication must be applied. The should-level requires strong passwords at minimum and stronger mechanisms for privileged users. For high protection needs, enhanced measures such as continuous session monitoring, automatic logout, and brute force prevention must be implemented based on the risk profile. For very high protection needs, access to data of very high classification must require strong two-factor authentication.

Evidence includes a risk assessment underpinning authentication choices, authentication configuration documentation, and at higher protection levels, records of enhanced access controls and monitoring.

4.1.3 — To what extent are user accounts and login information securely managed and applied?

User accounts must follow a clear lifecycle: creation, modification, and deletion all managed with oversight. Accounts must be unique and personal. Generic or shared accounts must be restricted to cases where traceability is genuinely not needed. Accounts must be disabled immediately when a user leaves or changes role. The should-level adds expectations around minimal default-privilege accounts, disabling of default manufacturer credentials, formal authorization procedures for creating accounts, and regular account reviews.

Evidence includes a user account management procedure, records of account creation and deactivation, and periodic access reviews.

4.2 Access Management

This subchapter addresses how access rights are granted, reviewed, and revoked — and how the organization ensures that rights remain aligned with actual need.

4.2.1 — To what extent are access rights assigned and managed?

Access rights must be managed based on the need-to-know and least privilege principles. The process for requesting, approving, and revoking rights must be defined. Rights must be revoked when no longer needed. The should-level expects role-based access control, with rights assigned to roles rather than individuals where possible, and regular reviews to identify stale or excessive rights. For high protection needs, access rights must be approved by a designated internal information officer. For very high protection needs, data of very high classification must be stored in encrypted form so that even privileged users cannot access it without appropriate authorization, and access rights must be reviewed more frequently.

Evidence includes an access rights management procedure, role definitions, access review records, approval records, and at higher protection levels, encryption configuration and formal information officer sign-off records.

The post ISA VDA 6.0.3 (part 3) — Information Security Sheet: Human Resources, Physical Security, Identity and Access Management first appeared on Sorin Mustaca – Security & Technology.

ISA VDA 6.0.3 (part 2) — Information Security Sheet: IS Policies and Organization

20/06/2026/in Educational

This is the part 2 of the series about the TISAX label: TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1).

ISA VDA 6.0.3 (part 2) — Information Security Sheet: IS Policies and Organization

Chapter 1 — IS Policies and Organization

This chapter establishes the governance foundation of the entire ISMS. It covers formal structures, policies, and management decisions that make information security a deliberate, managed discipline rather than an informal practice. Without a solid chapter 1, everything downstream has no authoritative basis.

1.1 Information Security Policies

This subchapter asks whether the organization has committed its approach to information security in writing and whether that commitment comes from the right level of authority.

1.1.1 — To what extent are information security policies available?

The organization must have at least one formally approved information security policy. This is not a technical document. It is a management-level statement that defines what information security means for the organization, why it matters, what the objectives are, and what roles and responsibilities exist. The policy must be adapted to the organization’s specific context, not copied wholesale from a template.

The must-level requirements demand that the policy exists, that it has been formally released by management, and that it articulates the objectives and significance of information security. The should-level requirements raise the bar: the policy should also reflect the organization’s strategic direction, applicable legal obligations, and contractual requirements. It should state what consequences follow from non-compliance, reference other relevant security policies, and be subject to periodic review. There are no additional requirements at the high or very high protection need levels for this control.

Evidence an auditor will look for: the policy document itself, a visible approval signature or release notation, version history showing periodic reviews, and communication records proving staff awareness.

1.2 Organization of Information Security

This subchapter addresses how information security is structured within the organization — who owns it, who is responsible for what, how it connects to projects, and how external IT service providers fit into the accountability picture.

1.2.1 — To what extent is information security managed within the organization?

The organization must have a functioning ISMS with a defined scope, management endorsement, and monitoring mechanisms that give leadership visibility into the state of information security. Management must have actively commissioned and approved the ISMS. Passive acceptance is not enough.

Evidence includes the ISMS scope statement, documented management approval, and any governance reporting tools or dashboards used by leadership to track security performance.

1.2.2 — To what extent are information security responsibilities organized?

Roles and responsibilities for information security must be defined, documented, and assigned to real, qualified people. Those people must be known within the organization and to relevant external parties. The should-level pushes toward a documented organizational structure covering all relevant security roles. For high protection needs, the control adds a requirement for appropriate separation of duties to prevent conflicts of interest — for example, ensuring the person who configures systems is not the same person auditing them.

Evidence includes role descriptions, organizational charts, and records of qualifications for people in security roles.

1.2.3 — To what extent are information security requirements considered in projects?

All projects, regardless of their nature, must be classified from an information security perspective so that relevant security requirements are identified early. The should-level expects a documented procedure for this classification, risk assessments at project initiation and when changes occur, and documented measures for any identified risks. For high protection needs, those measures must be reviewed regularly throughout the project lifecycle and reassessed whenever the risk picture changes.

Evidence includes a project classification procedure, risk assessment records for projects, and documented security measures tied to specific projects.

1.2.4 — To what extent are the responsibilities between external IT service providers and the own organization defined?

When the organization uses external IT services, it must be clear who is responsible for which security requirements. A shared model — where both parties have responsibilities — must be explicitly defined, not assumed. The should-level requires that configurations are implemented and documented based on security requirements and that responsible staff are adequately trained. For high protection needs, a formal list of all affected external IT services and their responsible providers must exist, the applicability of ISA controls must be verified and documented, service configurations must be included in regular security assessments, and proof must be available that the provider actually implements the agreed security requirements.

Evidence includes contracts or service agreements with security clauses, RACI matrices or responsibility assignment records, and provider compliance documentation.

1.3 Asset Management

This subchapter addresses whether the organization knows what information assets it holds, how they are classified, and whether the tools and external services used to process them are managed with appropriate controls.

1.3.1 — To what extent are information assets identified and recorded?

Information assets — the core data and knowledge that matter to the organization — must be identified and recorded, with a responsible owner assigned. The supporting technical assets that process those information assets must also be inventoried and assigned an owner. The should-level expects a formal catalogue that maps supporting assets to information assets and is reviewed regularly.

Evidence includes an asset inventory or register, assigned ownership records, and review logs for the catalogue.

1.3.2 — To what extent are information assets classified and managed in terms of their protection needs?

The organization must have a consistent classification scheme focused at minimum on confidentiality, and must have applied that scheme to its information assets. Handling requirements must follow from the classification. The should-level encourages the organization to also consider integrity and availability when classifying assets.

Evidence includes the classification scheme documentation, records of classification applied to specific information assets, and handling guidelines tied to each classification level.

1.3.3 — To what extent is it ensured that only evaluated and approved external IT services are used for processing the organization’s information assets?

Before using any external IT service to process organizational information, a risk assessment must be completed and legal, regulatory, and contractual requirements must be considered. The service must be harmonized with the organization’s information security requirements. The should-level expects a formal approval and procurement procedure, a release process tied to protection need, and a documented inventory of approved services. No additional high or very high requirements apply beyond regular checking of approved status.

Evidence includes risk assessment records for external services, approval documentation, a register of approved external IT services, and contract clauses.

1.3.4 — To what extent is it ensured that only evaluated and approved software is used for processing the organization’s information assets?

Software must be approved before installation or use, taking into account licensing, use-case restrictions, conformance to security requirements, and the reputation of the source. Approval must also address the removal of software that is no longer needed or no longer compliant. The should-level adds expectations around managed repositories, protection of those repositories against tampering, and regular review of approvals. For very high protection needs, additional requirements — such as control or monitoring of software usage — must be determined and documented.

Evidence includes a software approval process, a software inventory or repository, records of approvals and periodic reviews, and for very high protection needs, usage monitoring records.

1.4 IS Risk Management

This subchapter addresses the central mechanism that connects threats and vulnerabilities to the organization’s information assets and produces actionable decisions.

1.4.1 — To what extent are information security risks managed?

Risk assessments must happen regularly and in response to events, not only on a fixed annual schedule. Identified risks must be assessed for probability and potential damage, documented, and assigned to a responsible risk owner. The should-level requires a formal risk management procedure, defined criteria for assessing and handling risks, and documented plans with responsible persons. Accepted risks must be explicitly approved by management. No additional high or very high protection need requirements apply.

Evidence includes risk assessment records, a risk register, documented risk treatment decisions, and management approval records for accepted risks.

1.5 Assessments

This subchapter addresses the organization’s obligation to verify that its information security policies and ISMS are actually working, through both internal reviews and independent external assessments.

1.5.1 — To what extent is compliance with information security ensured in procedures and processes?

Policies must be checked for compliance throughout the organization on a regular basis. Deviations must trigger corrective measures, and those measures must be tracked to closure. Compliance with legal and contractual information security requirements must also be verified. The should-level expects a documented plan that defines the scope, schedule, and controls covered by compliance reviews.

Evidence includes compliance review reports, records of corrective actions, and a compliance review schedule or plan.

1.5.2 — To what extent is the ISMS reviewed by an independent authority?

The ISMS must be assessed from outside the team responsible for running it — by an internal audit function, an external auditor, or another body that can provide an objective view. This must happen regularly and whenever fundamental changes occur. Corrective measures arising from such reviews must be tracked. The should-level expects results to be formally reported to management.

Evidence includes internal audit reports or third-party review reports, management reporting records, and corrective action logs.

1.6 Incident and Crisis Management

This subchapter covers the organization’s capacity to detect, respond to, and recover from security incidents and, at a higher scale, from crisis situations that threaten continuity.

1.6.1 — To what extent are information security relevant events or observations reported?

There must be a clear definition of what constitutes a reportable security event, and this definition must be known to employees and relevant stakeholders. The definition must cover personnel-related events, physical security observations, and technical/cyber events. The should-level requires a single point of contact for reporting, multiple reporting channels matched to severity, and formal obligations for employees to report. For very high protection needs, tests and exercises of the reporting process must be conducted regularly.

Evidence includes the event reporting definition and procedure, communication records or training materials proving staff awareness, and for very high protection needs, exercise records.

1.6.2 — To what extent are reported security events managed?

Once an event is reported, it must be processed without undue delay, receive an adequate response, and feed into continuous improvement through lessons learned. The should-level expects events to be categorized by type, qualified by severity, and prioritized. For high protection needs, maximum response times must be defined for each class and priority, and escalation mechanisms must be in place for events not processed within those times. For very high protection needs, event handling across different categories and priorities must be tested regularly, including simulation of rare scenarios and escalation exercises.

Evidence includes a ticketing or event management system showing processing records, defined response time SLAs, escalation procedures, and exercise or simulation records at the appropriate protection level.

1.6.3 — To what extent is the organization prepared to handle crisis situations?

A crisis is a situation where normal incident response is insufficient — for example, a major cyberattack causing infrastructure failure, a pandemic, or a natural disaster. The organization must have a crisis response and recovery plan, defined responsibilities, and appropriately qualified personnel. The should-level adds requirements for methods to detect emerging crises, a procedure to invoke crisis management, and documented strategic priorities for crisis situations. For high protection needs, a set of relevant crisis scenarios must have been identified, covering key personnel unavailability, facility unavailability, and major cyberattacks, with corresponding response plans. For very high protection needs, full crisis exercises and simulations involving all relevant decision-makers must be conducted regularly.

Evidence includes a crisis management plan, documented responsibilities, evidence of tested scenarios, and exercise reports.

The post ISA VDA 6.0.3 (part 2) — Information Security Sheet: IS Policies and Organization first appeared on Sorin Mustaca – Security & Technology.

TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1)

04/06/2026/in Educational

TISAX — the Trusted Information Security Assessment Exchange — or Trusted ISA Exchange – is the automotive industry’s answer to a decades-old problem: every OEM was running its own supplier security questionnaire, and tier-1 and tier-2 suppliers were drowning in redundant audits. ENX Association, backed by the VDA (Verband der Automobilindustrie), formalized the exchange mechanism in 2017.

The result is a scheme where a single audit, conducted by an accredited assessment service provider (ASP), yields a result that any participating OEM can query via the ENX portal — no re-auditing required.

This series of articles is describing the requirements of the ISA and providing some insights.

How to get started

1. Download the TISAX Participant Handbook TISAX

This handbook applies to all TISAX processes that you may be part of. It contains all you need to know to run through the TISAX process. The handbook offers some advice on how to deal with the information security requirements at the core of the assessment.

But it does not aim to generally educate you on what you need to do to pass the information security assessment. Yes, you still need someone who actually understands how the controls in the next document.

2. Download the technical backbone of TISAX – the ISA — Information Security Assessment – currently at version 6.0.3 from here: workbook . The ISA is published by the VDA as an Excel workbook and serves simultaneously as the questionnaire, the scoring model, and the audit evidence tracker. Understanding its structure is not optional for any organization preparing for a TISAX assessment; it is the map of exactly what an auditor will walk through on-site.

What to do if you are a small company

For a small company, the TISAX assessment can be overwhelmingly complicated and … very expensive.
My advice to all small companies is to have a conversation with your TISAX certified customer which asked you to provide the label about the real needs.

In my experience, you can ask them to give you their Security Self-Assessment for Suppliers document (usually an Excel or PDF document) and you can fill it in.

Of course, you should be compliant to most of the security controls mentioned there.

If you think you are, you can fill in that document and discuss.

If you see clearly that you are not compliant, then try to negotiate down the requirements, focus on those that do not directly apply to the work you are doing for the customer.

If your customer wants to have a long-term working engagement with you (becoming a client) then it will have to make some compromises. Don’t forget that the bigger your company gets, the more important the security controls are.

If you will engage with other customers, in the end it might be that it makes perfect sense to become TISAX certified.

Assessment Levels and Label Scopes

Before examining the workbook itself, one distinction shapes everything: the Assessment Level.

AL1 is a self-assessment with no on-site verification.
AL2 requires a remote audit by an accredited ASP with evidence review and remote interviews.
AL3 demands a lot of preparation since it requires ultimately a mandatory on-site audit. Before the on-site audit, there is a phase for submitting evidence and having remote online interviews with key stakeholders. It is suitable for the highest-sensitivity scenarios — handling classified vehicle data, prototypes under embargo, or personal data processed on behalf of an OEM under GDPR data processor obligations.

Most suppliers in the automotive supply chain will be assessed at AL2 or AL3. The label a company requires determines which subset of the ISA they are audited against:Very High Protection Need, High Protection Need, Prototype Protection, or Data Protection .

The ISA workbook is structured to reflect this: it contains sheets for each major assessment domain, and the applicable controls per domain depend on the label scope agreed between the OEM and the supplier.

My company offers consulting on how to prepare for a TISAX and ISO27001 audit.

Get in touch with us here: https://www.endpoint-cybersecurity.com/contact/

The Workbook Sheet by Sheet

I will write separate articles about the important sheets: Information Security (part 2) and Data Protection (part 3).

Sheet 1 — Cover / Overview

The first sheet is the administrative header of the entire assessment. It captures the organization’s name, the assessment scope (which legal entity, which sites, which processes are in scope), the applicable label(s), and the assessment level. In practice, this sheet is also where the ASP documents the assessment date, the lead assessor’s identity, and the version of the ISA being used.

From an ISMS perspective, this sheet maps directly to the context of the organization requirement in ISO/IEC 27001:2022 (Clause 4). An organization that has already defined its ISMS scope in a formal Scope Statement will find that most of the Cover sheet data is already governed — the TISAX scope and the ISMS scope should be congruent, and any divergence is itself an audit finding waiting to happen.

Sheet 2 — Maturity Levels Reference

The ISA uses a six-level maturity scale (0 through 5) derived from the Capability Maturity Model (CMM) concept. Level 0 means the control is absent or completely ineffective. Level 5 means the control is continuously optimized and benchmarked. For a standard AL2 audit, the target threshold is level 3 (“established”) across applicable controls — meaning the process is documented, implemented, and verifiably practiced. AL3 assessments hold the same threshold but with more rigorous evidence scrutiny on-site.

This reference sheet is the normative scoring anchor for the entire workbook. Every self-assessment score entered elsewhere is implicitly a claim against these definitions, and auditors will challenge any score they cannot corroborate with observable evidence.

The ISMS parallel here is ISO 27001:2022 and ISO 27001:2013 Annex A combined with the organization’s Statement of Applicability. Just as the SoA records which controls apply and why, the maturity sheet defines what “implemented” means in quantified terms. Organizations that conflate “we have a policy” (Level 2) with “the policy is consistently followed and verified” (Level 3) routinely discover the gap when the auditor arrives.

Sheet 3 — Information Security (IS)

This is the largest and most foundational sheet in the workbook. It covers the full ISMS domain: organizational security, HR security, physical security, IT and network security, incident management, business continuity, cryptography, and supplier/third-party management. The controls are numbered in the VDA’s own scheme (e.g., 1.1.x, 1.2.x, 5.1.x) and each control row contains a requirement description, a column for the maturity self-assessment score, and columns for comments and evidence references.

The IS sheet is effectively a structured overlay on top of ISO/IEC 27001 Annex A (now restructured in the 2022 edition into four themes: Organizational, People, Physical, and Technological). The coverage is not identical — the ISA adds automotive-specific weight to areas like remote access for manufacturing systems, network segmentation between office and OT environments, and patch management for embedded systems. But the conceptual architecture is the same, and an organization holding an ISO 27001 certification will recognize every clause.

For ISMS practitioners, the critical translation exercise is mapping existing controls documentation (policies, procedures, risk treatment plans) to specific ISA control rows. The ISA does not accept “we are ISO 27001 certified” as a passing score; the auditor will still verify implementation evidence row by row. Certification reduces preparation effort but does not substitute for it.

Sheet 4 — Prototype Protection (PP)

The Prototype Protection sheet addresses a risk specific to the automotive industry: pre-production vehicles, components, and data carry enormous competitive value. Photographs of an unreleased platform at a supplier’s facility have ended up in press publications before launch day more than once. This sheet governs the physical and logical protection of prototype parts and vehicles when they are handled by suppliers — covering receiving and storage, access control to prototype areas, handling of prototype data in digital form (CAD files, test results, specification documents), and obligations when prototypes are transported or loaned.

The PP sheet has no direct ISO 27001 Annex A equivalent, though it draws on physical security principles from that standard. Its closest ISMS relatives are the asset classification and handling controls (A.5.9–A.5.13 in ISO 27001:2022) and the physical security perimeter controls (A.7.1–A.7.4). Organizations that handle prototypes but have not explicitly extended their ISMS asset register to cover physical prototype inventory — and their ISMS physical security controls to cover prototype bays specifically — will find gaps here.

The Prototype Protection label is only triggered when an OEM explicitly requires it in the exchange request. Not every supplier will be assessed on this sheet, but those who are should expect the auditor to physically walk the relevant areas.

Sheet 5 — Data Protection (DP)

The Data Protection sheet was substantially expanded in ISA 6.x to reflect the obligations introduced by GDPR for automotive suppliers acting as data processors on behalf of OEMs. It covers the legal basis for personal data processing, ROPA (Records of Processing Activities) maintenance, data subject rights procedures, DPIA (Data Protection Impact Assessment) processes for high-risk processing, technical and organizational measures (TOMs) as required under GDPR Article 32, data breach notification timelines, and SCCs (Standard Contractual Clauses) for international data transfers.

From an ISMS alignment perspective, this sheet crosses a boundary: it is no longer purely an information security matter but a legal compliance matter rooted in Regulation (EU) 2016/679. ISO 27001 does not fully satisfy the DP sheet — ISO/IEC 27701:2019 (the Privacy Information Management System extension to 27001) is the closest standards-based alignment. Organizations that have implemented 27701 or maintained a structured GDPR compliance program will have significant coverage, but the ISA’s DP sheet is more prescriptive and automotive-context-specific than the generic 27701 controls.

The Data Protection label, like the Prototype Protection label, is triggered selectively. Suppliers who process employee or end-customer personal data on behalf of an OEM — telematics data processors are the clearest example — will routinely be required to achieve it.

Sheet 6 — Results / Summary

The final sheet aggregates the per-control scores from the assessment sheets into domain-level and overall maturity summaries. It typically presents a radar or bar visualization of maturity per domain and flags controls scored below the threshold, which constitute findings. Findings are classified as either major (blocking label issuance) or minor (requiring a remediation plan within a defined timeframe, typically 6–12 months).

For audit management purposes, this sheet is the executive communication artifact. It is what a CISO presents to the board when reporting TISAX readiness, and it is what the ASP uses to structure the final assessment report submitted to ENX. In an ISMS context, this sheet’s function mirrors the management review output required under ISO 27001 Clause 9.3 — a documented evidence of the current state of the security posture, with identified nonconformities and corrective action owners.

The Practical Implication

The ISA workbook is not a compliance checklist to be filled in once every three years, even if it is know that this is a common practice among small-medium companies.

It is supposed to be a living snapshot of a security posture. Organizations that treat it as a periodic exercise tend to discover, during reassessment, that improvements logged in the previous cycle were never fully operationalized.

The workbook’s value is highest when it is maintained continuously as a management tool — updated as the threat landscape changes, as new processing activities begin, as infrastructure is modified, and as supply chain relationships evolve.

For companies already operating an ISO 27001-compliant ISMS, the ISA workbook is best understood as the automotive industry’s structured lens on that ISMS: it asks the same fundamental questions about governance, risk, and control, but through the specific context of the VDA’s risk model and the contractual obligations of the automotive supply chain.

Closing the gap between the two is the core of any effective TISAX preparation program.

How about doing everything with AI ?

AI can help, but can’t solve the problem for you. Well, you can try, but the results are … well, I better let you test it yourself.
The problem is that you need to run through the AI all your ISMS (all policies, procedures) and compare its content with the controls in ISA.
But this is not everything: you not only need to map policies to controls, you must also provide the right evidence for them. This is very problematic, since no AI at this point in time is able to comprehend the multitude of types of evidence: logs, pictures, powerpoint presentations, xls documents, etc.

I have not seen this working good so far in several AI-powered solutions on the market.

Btw, those solutions are LLMs trained with a lot of context for the respective certification and they are not made to work just for TISAX. That’s why they don’t work good.

My company offers consulting on how to prepare for a TISAX and ISO27001 audit.

Get in touch with us here: https://www.endpoint-cybersecurity.com/contact/

The post TISAX getting started: A Deep Dive into the ISA Assessment Workbook (part 1) first appeared on Sorin Mustaca – Security & Technology.

AI Adoption for companies in the USA

28/05/2026/in Educational

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.