Posts

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

/in

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

/in

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

/in

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

/in

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

/in

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)

/in

 

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.

SOC 2 Type 2 mapping to Secure SDLC Requirements

/in

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

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

 

SOC 2 Type 2 and Secure SDLC — the big picture

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

Summary mapping of SOC2 controls to SDLC

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

 

Practical Checklist — SDLC Evidence by Common Criteria

CC1 — Control environment

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

CC2 — Communication

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

CC3 — Risk assessment

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

CC4 — Monitoring activities

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

CC5 — Control activities

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

CC6 — Logical access

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

CC7 — System operations

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

CC8 — Change management

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

CC9 — Risk mitigation

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

Secure SDLC and SOC 2 Type 2 — Summary

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

 

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

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

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

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

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

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

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

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

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

EU Cyber Resilience Act (CRA) – Overview

/in

What is the Cyber Resilience Act – CRA

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

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

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

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

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

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

Timeline & Legal Effect

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

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

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

*CABs = Conformity Assessment Bodies

Source: BSI

Key Requirements & Obligations

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

Secure-by-design and secure-by-default

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

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

Lifecycle security

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

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

Vulnerability & incident reporting

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

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

Documentation & traceability

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

CE-marking with security

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

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

Conformity assessments for higher-risk products

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

Why It Matters

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

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

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

 

CRA Product Classification

Criteria & Examples

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

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

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

 

Assessment & conformity requirements per class

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

  • Default Category – non-critical, low inherent risk

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

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

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

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

Examples of Software Products Classification

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

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

 

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

 

Further reading and sources

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

NIS2 Fulfillment through TISAX Assessment and ISA6

/in

ENX has released an interesting article about how NIS2 requirements map to TISAX requirements. For this, there is a short introductory article called “TISAX and Cybersecurity in Industry – Expert Analysis Confirms NIS2 Coverage” and

and a full article of 75 pages : https://enx.com/TISAX-NIS2-en.pdf

An analysis conducted within ENX’s expert working groups examined how well a TISAX assessment based on the ISA6 catalog aligns with the requirements of the NIS2 Directive.

The key findings include:

  • All relevant NIS2 requirements are addressed, including risk management, incident response, supply chain security, governance, and technical safeguards.
  • TISAX goes beyond minimum legal requirements, incorporating structured maturity assessments, systematic vulnerability management, and continuous improvement mechanisms.
  • The established three-year assessment cycle is considered appropriate in the context of NIS2.
  • TISAX labels are publicly accessible via the ENX database, enabling transparent verification.
  • Additional national requirements must be addressed separately. This includes, in particular, country-specific reporting obligations to authorities or national CSIRTs. While not part of the TISAX standard, these requirements can be effectively managed using existing TISAX structures.

 

Here is the summary of the PDF above created with NotebookLM (9 pages):

Detailed Briefing Document: NIS2 Fulfillment Through TISAX

Date: October 26, 2023 Prepared for: Key Stakeholders concerned with NIS2 Compliance in the Automotive Industry Subject: Review of the “NIS2 fulfilment through TISAX” Expert Opinion, detailing how TISAX assessments align with NIS2 Directive requirements.

Executive Summary

The automotive industry, through the ENX Association and the ISA requirements catalogue, has proactively addressed cybersecurity for years, culminating in the TISAX assessment standard established in 2017. This expert opinion, published by the ENX Association, concludes that companies with TISAX-compliant sites fully implement the requirements of the NIS2 Directive. The ISA catalogue and TISAX assessments go beyond NIS2 requirements, defining and continuously upholding the “state of the art” in information and cybersecurity for the industry. Independent auditors confirm implementation in a three-year cycle, deemed appropriate even when compared to the two-year cycle for critical infrastructure operators under German law. A common exchange mechanism allows organizations to query TISAX status and, by extension, NIS2 compliance, of partners.

Key Takeaway: Organizations with a valid TISAX label are generally well-prepared for the material requirements of NIS2, with the caveat that they must still manage national reporting requirements in parallel and ensure that their TISAX assessment objectives reflect their overall risk and cover all NIS2-affected sites.

1. Introduction and Overview of NIS2 and TISAX

The NIS2 Directive (EU) 2022/2555 aims to strengthen cyber resilience across the European Union, replacing the NIS1 Directive. It expands the scope of affected organizations, including many in the automotive industry. The automotive industry recognized the need for industry-wide information and cybersecurity and developed the TISAX Assessment standard and its underlying ISA requirements catalogue. The purpose of this analysis is to demonstrate that TISAX assessments, based on ISA6, can be considered proof of compliance with NIS2 requirements.

  • Purpose of Analysis: To assist companies in the automotive industry in assessing whether TISAX compliance covers NIS2 requirements.
  • Scope of Analysis: Focuses exclusively on NIS2 Directive requirements with specific implementation guidelines for companies. It does not provide implementation assistance or confirm a company’s readiness for NIS2 outside of TISAX. Country-specific implementations and additional material requirements are not covered.
  • Target Audience: Experts from companies affected by NIS2 that use or undergo TISAX assessments, and authorities responsible for NIS2 compliance and supervision.

2. TISAX Assessment and Underlying Catalogue of Requirements (ISA6)

TISAX assessments, conducted by independent auditors in a three-year cycle, are based on ISA catalogue version 6 (ISA6). A critical distinction is made between TISAX scope definition and ISO management system certifications:

  • TISAX Assessment Scope: Utilizes a generally defined standard scope, ensuring comparability and a similar level of security across companies. This contrasts with ISO/IEC 27001, where the audited organization defines its ISMS scope. For the conclusions of this document to apply, TISAX Assessment objectives must reflect the company’s overall risk, and all NIS2-affected sites must have corresponding TISAX labels.
  • TISAX Assessment Objectives: Allow for scaling the assessment content based on risk and criticality of information processed (e.g., Confidential, Strictly Confidential, High Availability, Very High Availability, Data, Special Data, Prototype Protection).
  • TISAX Assessment Levels (AL):AL 1: Self-assessment, auditor checks completion, low confidence, not used in TISAX.
  • AL 2: Auditor performs plausibility check of self-assessment, checks evidence, conducts interviews (usually web conference).
  • AL 3: Comprehensive review, auditor verifies documents, conducts planned and unplanned interviews, observes implementation, and considers local conditions. Generally takes place on-site at all locations.
  • If multiple objectives are used, the highest AL is applied to the overall assessment.
  • TISAX Group Assessments (Simplified Group Assessment – SGA): Designed for companies with many locations and a centralized, highly developed ISMS.
  • S-SGA (Sample-based): Main site extensively assessed, sample sites assessed, other sites assessed at one AL lower.
  • R-SGA (Rotating Schedule-based): Main site extensively assessed, other locations assessed at the same AL but distributed over the three-year validity period. Not available for prototype protection objectives.
  • TISAX Control Questions and Requirements:Requirements are categorized (Must, Should, Additional requirements for high protection needs, Additional requirements for very high protection needs, Additional requirements for SGA).
  • “Must” requirements are strict, “Should” allows for justified deviations.
  • Additional requirements are subdivided by protection objectives (Confidentiality (C), Integrity (I), Availability (A)).
  • Individual control questions cannot be excluded as “not applicable”; they must be implemented holistically.
  • Deviations in TISAX Model: TISAX includes a maturity model (six levels, target is “established”) to assess practical implementation. Identified deviations require corrective action plans with defined implementation periods (up to 3, 6, or 9 months). Failure to correct deviations results in a failed audit.
  • Validity Period: TISAX assessments are valid for three years. Companies must continuously implement specified measures, conduct regular internal audits, and report significant changes affecting the ISMS or physical conditions, potentially requiring interim assessments.

3. NIS2 Article 20: Governance and Training

NIS2 Article 20 focuses on the governance body’s responsibility for cybersecurity risk management and their participation in relevant training.

  • NIS2 Article 20 (1): Governing Body’s Role in Risk Management: Requires the governing body to establish and monitor structures for cybersecurity risk management.
  • TISAX Fulfilment: Fully covered by ISA6 controls (1.2.1, 1.2.2, 1.4.1, 1.5.1, 1.5.2, 7.1.1). These controls check for defined ISMS scope, determined requirements, management commissioning and approval of ISMS, communication channels, regular reviews of ISMS effectiveness, defined responsibilities, resource availability, adequate security structure, qualified employees, conflict of interest avoidance, regular risk assessments, risk classification and allocation, security risk handling, compliance verification, independent ISMS reviews, and consideration of regulatory/contractual provisions.
  • Summary: “The requirement that the governing body of an organization has created appropriate structures to implement and monitor the implementation of the cybersecurity risk management measures taken to comply with Article 21 (NIS2 Article 20 (1)) is described by the controls defined in the ISA6 assessment standard and is fully checked for existence and implementation by the responsible auditor within a TISAX assessment.” The three-year TISAX cycle is considered appropriate given NIS2’s risk-based approach.
  • NIS2 Article 20 (2): Training for Governing Body and Relevant Members: Requires regular training for governing body members and other relevant individuals to acquire sufficient knowledge and skills in cybersecurity risk identification, assessment, and management.
  • TISAX Fulfilment: Checked by ISA6 control 2.1.3 (“To what extent is staff made aware of and trained with respect to the risks arising from the handling of information?”). This includes comprehensive training for all employees (including management), an awareness training concept covering relevant areas, consideration of target groups, regular execution, and documentation of participation.
  • Summary: While ISA does not explicitly list “management body” for training, it mandates training for “all employees” and differentiation by “target group,” implicitly covering management. This ensures the requirements of NIS2 Article 20 (2) are met.

4. NIS2 Article 21: Risk Management Measures

NIS2 Article 21 mandates appropriate and proportionate technical, operational, and organizational measures to manage risks to network and information systems.

  • NIS2 Article 21 (1): General Measures for Risk Management: Requires appropriate and proportionate measures to manage risks and minimize incident impact, considering the state of the art and implementation costs.
  • TISAX Fulfilment: Covered by ISA6 controls 1.2.1 (“To what extent is information security managed within the organization?”) and 1.4.1 (“To what extent are information security risks managed?”). These check for defined ISMS scope, determined requirements, existence and regular updating of risk assessments, assignment of risk owners, and action plans for risks.
  • Summary: “The requirements of NIS2 Article 21 (1) are described by the controls defined in the ISA6 assessment standard and are checked for existence and implementation by the auditor responsible during a TISAX assessment.” The TISAX assessment ensures a risk-based approach tailored to the company’s circumstances.
  • NIS2 Article 21 (2) a) – j): Specific Measures: These sub-articles detail specific areas for cybersecurity measures.
  • a) Policies on Risk Analysis and Information System Security: Fully covered by ISA6 controls 1.4.1, 5.2.7, 5.3.1, checking for procedures to identify, assess, and address risks, network management requirements, and information security consideration in new/developed IT systems.
  • b) Incident Handling: Fully covered by ISA6 controls 1.6.1, 1.6.2, checking for definition of reportable events, reporting channels, communication strategies, and incident processing procedures (categorization, qualification, prioritization, response, escalation). “The processes for detection, reporting channels and procedures, classification, processing and escalation (if necessary), go beyond the requirements stipulated in NIS2.”
  • c) Business Continuity, Backup Management, Disaster Recovery, Crisis Management: Fully covered by ISA6 controls 1.6.3, 5.2.8, 5.2.9, checking for crisis management preparedness, IT service continuity planning, and backup/recovery of data and IT services.
  • d) Supply Chain Security: Fully covered by ISA6 controls 1.2.4, 1.3.3, 1.6.1, 1.6.2, 1.6.3, 5.3.3, 6.1.1, 6.1.2. This includes defining responsibilities with external IT service providers, ensuring use of evaluated services, incident reporting and management from external parties, secure removal of information from external services, ensuring information security among contractors and partners, and contractual non-disclosure agreements. “The requirements in the ISA6 assessment standard go beyond the requirements of NIS2 and additionally include, for example, compliance with information security standards beyond the direct providers or service providers.”
  • e) Security in Network and Information Systems Acquisition, Development, and Maintenance (including vulnerability handling): Fully covered by ISA6 controls 1.2.3, 1.2.4, 1.3.4, 5.2.1, 5.2.4, 5.2.5, 5.2.6, 5.3.1, 5.3.2, 5.3.3, 5.3.4. This extensive coverage includes considering information security in projects, responsibilities with external IT service providers, approved software usage, change management, event logging, vulnerability identification and addressing, technical checks of IT systems, security in new/developed IT systems, network service requirements, and information protection in shared external services. “The assessment goes beyond the requirements of NIS2 by considering the return and secure removal of information assets from IT services outside the organization.”
  • f) Policies and Procedures to Assess Effectiveness of Cybersecurity Risk-Management Measures: Fully covered by ISA6 controls 1.2.1, 1.4.1, 1.5.1, 1.5.2, 1.6.2, 5.2.6, checking for regular review of ISMS effectiveness by management, up-to-date risk assessments, regular compliance checks, independent ISMS reviews, continuous improvement based on security events, and regular technical audits of IT systems and services. The three-year cycle is considered appropriate.
  • g) Basic Cyber Hygiene Practices and Cybersecurity Training: Covered by a wide range of ISA6 controls (1.1.1, 2.1.2, 2.1.3, 4.1.3, 4.2.1, 5.1.1, 5.1.2, 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.2.5, 5.2.6, 5.2.7, 5.2.8, 5.2.9, 5.3.1, 5.3.2, 5.3.3, 5.3.4). This includes information security policies, contractual obligations for staff, comprehensive training, secure management of user accounts/login info, access rights management, cryptographic procedures, information protection during transfer, change management, separation of environments, malware protection, event logging, vulnerability management, technical audits, network management, continuity planning, backup/recovery, and secure handling of information assets.
  • h) Policies and Procedures Regarding Cryptography and Encryption: Fully covered by ISA6 controls 5.1.1, 5.1.2, checking for adherence to industry standards, technical rules, lifecycle management of cryptographic keys, key sovereignty, and protection of information during transfer (including encryption).
  • i) Human Resources Security, Access Control Policies, and Asset Management: Fully covered by a comprehensive set of ISA6 controls (1.3.1, 1.3.2, 1.3.3, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 3.1.3, 3.1.4, 4.1.1, 4.1.2, 4.1.3, 4.2.1, 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.2.5, 5.2.6, 5.2.7, 5.2.8, 5.2.9). This includes identification and classification of information assets, use of approved external IT services, employee qualification for sensitive roles, contractual obligations, training, mobile work regulations, handling of supporting assets, mobile device management, identification means management, user access security, user account/login info management, access rights, change management, separation of environments, malware protection, event logging, vulnerability management, technical audits, network management, continuity planning, and backup/recovery.
  • j) Multi-factor Authentication, Continuous Authentication, Secured Communications, and Emergency Communication Systems: Fully covered by ISA6 controls 1.6.3, 4.1.2, 4.1.3, 5.1.2, 5.2.8. This involves crisis planning for communication, user authentication procedures (including strong authentication/MFA for privileged accounts), secure management of user accounts/login info, protection of information during transfer (secure voice/video/text communication), and continuity planning that includes alternative communication strategies.
  • NIS2 Article 21 (4): Immediate Corrective Measures for Non-Compliance: Requires immediate necessary, appropriate, and proportionate corrective measures upon awareness of non-compliance with Article 21 (2) measures.
  • TISAX Fulfilment: Fully covered by ISA6 controls 1.5.1, 1.5.2, checking for verification of policy observation, regular review of policies/procedures, documented results, regular compliance checks, and initiation/pursuit of corrective measures based on internal and independent reviews. The three-year cycle is deemed appropriate.

5. NIS2 Article 23: Incident Reporting

NIS2 Article 23 outlines requirements for reporting security incidents.

  • NIS2 Article 23 (1): Notification of Significant Security Incidents: Essential and important entities must notify their CSIRT or competent authority without undue delay of significant security incidents. Recipients of services must also be informed immediately. Information enabling cross-border impact determination must be provided.
  • TISAX Fulfilment: Almost fully met by ISA6 controls 1.6.1, 1.6.2. These check for defined reportable events, known reporting mechanisms based on severity, available reporting channels, handling of events by category, knowledge of reporting obligations and contact information, and communication strategies.
  • Summary: “One exception here is the disclosure of cross-border effects, which is not explicitly required within the ISA. It has already been defined here that emergency communication must be expanded to include the specifications from NIS2. Once this extension has been considered, the requirements are fully met.”
  • NIS2 Article 23 (2): Communication of Remedial Actions to Recipients: Entities must promptly communicate to affected recipients any measures or remedial actions they can take in response to a significant cyber threat, and inform them of the threat itself.
  • TISAX Fulfilment: Covered by ISA6 control 1.6.2. This includes categorization, qualification, and prioritization of reported events, appropriate responses, and communication strategies considering target recipients and reporting periods.
  • Summary: “The explicit contact information, reporting channels and languages must be included in the Business Continuity Management (BCM) by the companies following their publication by the EU member states. The auditor cannot guarantee that this information is available, as the information to be included is company-specific and can therefore take a variety of forms.”
  • NIS2 Article 23 (3): Definition of Significant Security Incident: Provides an informative definition (serious disruption or financial/material/immaterial damage).
  • TISAX Fulfilment: Purely informative, no assessable measures.
  • NIS2 Article 23 (4): Reporting Timelines and Content: Specifies detailed reporting timelines (early warning within 24 hours, incident notification within 72 hours, intermediate reports, final report within one month).
  • TISAX Fulfilment: Covered by ISA6 controls 1.6.1, 1.6.2, 1.6.3. These check for defined reportable events, mechanisms based on severity, accessible reporting channels, obligation to report, feedback procedures, categorization/prioritization, maximum response times, escalation, and crisis communication strategy.
  • Summary: “In addition to the knowledge and existence of the necessary reporting channels and deadlines, the ISA standard also requires the establishment of crisis-proof communication. At this point, the requirements of the ISA go beyond the requirements of NIS2.” Similar to 23(2), explicit contact information and channels are company-specific and not directly assessed by TISAX.
  • NIS2 Article 23 (5-11): No explicit demands on affected companies requiring preparatory measures.

6. NIS2 Article 24

  • NIS2 Article 24 (1): No explicit demands on affected companies that require preparatory measures.
  • TISAX Fulfilment: No assessable measures.

7. NIS2 Article 25: European and International Standards

NIS2 Article 25 addresses the application of European and international standards for network and information system security.

  • TISAX Fulfilment: “The requirements of NIS2 Article 25 to use European and international standards and technical specifications for the security of network and information systems to ensure the implementation of the requirements for companies resulting from NIS2 are met by an audit of an organization’s ISMS carried out in accordance with TISAX, as this report demonstrates.” No explicit demands for preparatory measures are made on companies.

8. NIS2 Articles 22, 26-29

  • NIS2 Article 22: Coordinated Risk Assessments for Critical Supply Chains: No specific requirements for companies, not considered further in this report.
  • NIS2 Articles 26-28 (Jurisdiction, Register of Entities, Domain Name Registration Data): No measures to be examined for companies, not considered in this document.
  • NIS2 Article 29: Exchange of Cybersecurity Information: “The requirements of NIS2 Article 29 are not assessed within the TISAX assessment.”

9. Overall Summary and Conclusion

The “NIS2 fulfilment through TISAX” document strongly asserts that TISAX assessments, based on the ISA requirements catalogue, provide comprehensive evidence that companies meet the material requirements of the NIS2 Directive.

  • State of the Art: ISA and TISAX are considered “state of the art” for information and cybersecurity in the automotive industry due to their continuous development by experts, application by thousands of companies, and resulting knowledge gain.
  • Management Responsibility and Risk Management: A TISAX label indicates that the management of an assessed company fulfills the responsibility required in NIS2 Article 20 and has implemented all state-of-the-art risk management measures of Article 21, provided the assessment objectives reflect overall risk and all NIS2-affected sites were included.
  • Audit Cycle: The three-year TISAX audit cycle is deemed appropriate, even compared to the two-year cycle for critical infrastructure operators under German law, due to the continuous monitoring and documentation obligations within the cycle.
  • Preparation for NIS2: Companies with a valid TISAX label are “well positioned to meet the requirements of the NIS2 directive in these areas.”
  • Reporting Requirements: TISAX provides proof of established mechanisms for mandatory reporting to authorities and customers. However, companies are responsible for integrating country-specific additional requirements and verifying them against implemented measures.

In essence, TISAX is presented as a robust framework that aligns with and often exceeds the cybersecurity requirements set forth by NIS2 for the automotive sector.

 

 

The post NIS2 Fulfillment through TISAX Assessment and ISA6 first appeared on Sorin Mustaca’s blog.

Comparing “Records of Processing Activities” (ROPA) and “Data Protection Impact Assessments” (DPIA) (with Podcast)

/in

Understanding ROPA and DPIA: Key GDPR Concepts for Tech Companies

Podcast of this article:


 

 

 

Let’s explore two essential components of GDPR compliance: Records of Processing Activities (ROPA) and Data Protection Impact Assessments (DPIA).

ROPA provides a comprehensive overview of your data handling, while DPIA focuses on assessing and mitigating risks for specific, higher-risk activities.

Records of Processing Activities (ROPA): Your Company’s Data Map

Think of ROPA as your company’s data map. It documents every step of the data journey, from collection to deletion.

It’s about what data you collect, including why, how, and with whom you share it.

A well-maintained ROPA is crucial for demonstrating GDPR compliance and building trust with your users.

What ROPA Covers

  • Purposes of Processing: Be specific! Instead of “marketing,” say “personalized email marketing based on user browsing history” or “improving product recommendations based on user purchase data.”
  • Categories of Data Subjects: Identify who the data relates to (e.g., customers, employees, website visitors, app users).
  • Categories of Personal Data: List the types of data you process (e.g., name, email address, IP address, location data, browsing history, biometric data).
  • Recipients of Personal Data: Specify who you share data with (e.g., cloud storage providers, marketing agencies, analytics platforms, law enforcement). Include both internal and external recipients.
  • Transfers to Third Countries: If you transfer data outside the EU, document the safeguards in place (e.g., adequacy decisions, standard contractual clauses).
  • Data Retention Periods: Specify how long you keep different types of data. This should be based on legal requirements and business needs.
  • Technical and Organizational Security Measures: Briefly describe the security measures you have in place to protect the data (e.g., encryption, access controls, data masking).

ROPA Examples for Tech Companies

  • Social Media Platform: A social media platform’s ROPA would detail processing activities related to user profiles, posts, photos, friend connections, messaging, targeted advertising, and data analytics. It would specify data categories (e.g., profile information, IP address, location data, browsing history), purposes (e.g., personalized content delivery, targeted advertising, platform improvement), and recipients (e.g., advertising partners, analytics providers).
  • SaaS Provider: A SaaS provider’s ROPA would document processing related to user account management, data storage, application usage tracking, customer support interactions, and billing. It would include details about data categories (e.g., user credentials, company data, usage logs), purposes (e.g., providing the service, improving performance, customer support), and recipients (e.g., cloud hosting providers, payment processors).
  • Mobile App Developer: A mobile app developer’s ROPA would cover data processing within the app, such as collecting user location data for personalized recommendations, accessing contacts for social features, or tracking in-app purchases. It would detail the data categories (e.g., location, contacts, purchase history), purposes (e.g., personalized recommendations, social features, in-app advertising), and recipients (e.g., location services providers, advertising networks).

Data Protection Impact Assessments (DPIA): Proactive Risk Management

A DPIA is a more in-depth analysis triggered by specific processing activities that pose a high risk to individuals.

With the DPIA you’re identifying risks, and also finding ways to mitigate them and demonstrating that you’ve considered data protection all the way.

What DPIA Covers

  • Description of the Processing Operations: Clearly explain the planned processing, including the purposes, data categories, and processing methods.
  • Necessity and Proportionality: Justify why the processing is necessary and proportionate to the intended purpose. Are there less intrusive ways to achieve the same goal?
  • Assessment of Risks to Individuals: Identify potential risks to individuals’ rights and freedoms, such as identity theft, discrimination, loss of control over their data, or reputational damage. Consider the likelihood and severity of these risks.
  • Measures to Address the Risks: Describe the measures you will implement to mitigate the identified risks. This might include technical measures (e.g., encryption, anonymization), organizational measures (e.g., access controls, data minimization policies), and legal measures (e.g., data processing agreements).
  • Consultation with Data Protection Authorities (DPA): In some cases, you may need to consult with your local DPA before carrying out high-risk processing.

DPIA Examples for Tech Companies

  • Facial Recognition Software: A company developing facial recognition software for security purposes would need a DPIA. The DPIA would assess risks related to accuracy, bias, potential for misuse, and impact on individuals’ privacy and freedom of movement. Mitigation measures might include strict access controls, data anonymization techniques, and clear guidelines for use.
  • AI-Powered Recommendation Engine: A company launching a new AI-powered personalized recommendation engine that analyzes large volumes of user data would require a DPIA. The DPIA would analyze the risks of profiling, discrimination, and loss of privacy. Mitigation measures could include data minimization, differential privacy techniques, and user consent mechanisms.
  • Biometric Authentication: A company implementing large-scale biometric authentication for access control would need a DPIA. The DPIA would evaluate the risks of data breaches, identity theft, and potential misuse of biometric data. Mitigation measures could include secure storage of biometric data, multi-factor authentication, and strict access controls.

ROPA and DPIA: Similarities and Differences

ROPA and DPIA are like two sides of the same coin – both essential for responsible data handling under GDPR. They work together to ensure your data processing is transparent, accountable, and respects individuals’ privacy.

Similarities

  • GDPR Compliance:
    • Both ROPA and DPIA are mandated by the GDPR (Articles 30 and 35, respectively).
    • They’re not optional; they’re legal requirements for many organizations.   
  • Focus on Data Protection:
    • At their core, both aim to protect individuals’ rights and freedoms related to their personal data.
    • They promote a privacy-first approach to data processing.
  • Documentation is Key:
    • Both require thorough documentation.
    • ROPA is the documented record of your processing activities, and DPIA results in a documented risk assessment report.
    • Good record-keeping is crucial for demonstrating compliance.   
  • Accountability:
    • Both contribute to demonstrating accountability.
    • By maintaining a ROPA and conducting DPIAs, you show that you’re taking data protection seriously and actively managing risks. 

Differences

  • Scope:
    • ROPA covers all your data processing activities,
    • DPIA focuses on specific, high-risk processing activities.
    • Think of ROPA as the big picture and DPIA as a focused close-up.
  • Purpose:
    • ROPA’s primary purpose is to document and provide transparency about all your data processing.
    • DPIA’s main goal is to assess and mitigate the risks of particular processing activities that are likely to be high-risk.  
  • Requirement:
    • ROPA is a general requirement for most organizations (especially those with over 250 employees or those processing sensitive data).
    • DPIA is only required when processing activities are likely to result in a high risk to individuals’ rights and freedoms. It’s triggered by specific circumstances.
  • Outcome:
    • ROPA produces a comprehensive record of your processing activities.
    • DPIA results in a risk assessment report outlining potential risks and the measures you’ll take to mitigate them.
    • One is a detailed inventory, the other a focused risk analysis.  
  • Timing:
    • ROPA is an ongoing requirement – you need to keep it updated as your processing activities change.
    • DPIA is conducted for specific projects or plans before they are implemented. It is a point-in-time assessment. 

In a nutshell:

  • ROPA is your ongoing data processing inventory, demonstrating your overall approach to data protection.
  • DPIA is a targeted risk assessment for specific, potentially high-risk projects, ensuring you’ve considered and addressed privacy concerns before they become a problem.
  • Both are essential tools in your GDPR compliance toolkit.

The post Comparing “Records of Processing Activities” (ROPA) and “Data Protection Impact Assessments” (DPIA) (with Podcast) first appeared on Sorin Mustaca on Cybersecurity.