# Enterprise AI Security Programme: ISO/IEC 42001, NIST AI RMF and Secure AI SDLC

**URL:** https://securesys.com.tr/en/learning/software-and-ai-security/enterprise-ai-security-iso-42001-and-nist-ai-rmf

![Enterprise AI Security Programme: ISO/IEC 42001, NIST AI RMF and Secure AI SDLC](/images/bilgi-merkezi/covers/cover-yzguv-12.webp)

### Introduction: AI Security Is Now a Matter of Corporate Governance

Artificial intelligence technologies are changing the way organisations work.

Employees use large language models to speed up their daily tasks.

Software teams use AI-assisted code development tools.

Finance departments are automating their data analyses.

Human resources teams can use AI applications in candidate evaluation processes.

Customer service operates with AI-powered assistants.

Security operations use AI-assisted incident analysis systems.

In addition, AI Agent technologies make it possible to build systems that can carry out actions in specific business processes rather than merely offering recommendations.

These developments create significant opportunities.

However, the spread of AI use also brings new corporate responsibilities.

Which AI systems are in use?

Who owns these systems?

Which data is being processed?

Which models and service providers have been chosen?

What is the effect of AI decisions on business processes?

What security risks exist?

How are these risks measured?

How is the effectiveness of security controls verified?

When a security incident occurs, which team will respond?

The answers to these questions cannot be left to the information technology department alone.

This is because AI security is directly tied to the responsibilities of information security, software development, data protection, legal, compliance, risk management and senior management.

For this reason, organisations need not just individual AI security products but a sustainable **Enterprise AI Security Programme**.

In this article, we examine how such a programme can be designed, which international frameworks can be drawn upon, and how technical security controls can be combined with corporate governance.

### \1. What Is Enterprise AI Security?

Enterprise AI security is the whole of the technical, administrative and operational controls aimed at managing the security risks of the AI systems that an organisation develops, buys or uses.

This approach does not focus on model security alone.

It covers the entire lifecycle of the AI system.

#### Core security areas

- AI governance.
- Model and application inventory.
- Risk assessment.
- Data security.
- Identity and access management.
- Secure development.
- Model security.
- Supply chain security.
- AI Agent authorisation.
- Security testing.
- Monitoring and incident response.
- Continuous improvement.

The aim of an enterprise programme is to keep AI use aligned with security and governance requirements.

### \2. Why Can AI Security Not Be Achieved with a Single Product?

An organisation can use an AI Gateway.

It can deploy a Prompt Firewall.

It can control sensitive data transfers with a DLP solution.

It can carry out an LLM Pentest.

However, each of these controls focuses on specific risks.

For example, an AI Gateway can control certain parts of model communication.

But it cannot, on its own, verify the trustworthiness of the training dataset.

DLP can reduce the transfer of sensitive data.

But it cannot, on its own, prevent an AI Agent from holding overly broad permissions in business processes.

An LLM Pentest can identify specific security vulnerabilities.

But it does not guarantee that new models and integrations will remain secure over time.

For this reason, organisations need to build a layered security approach.

**AI security is not a product; it is a continuous programme made up of process, technology, people and governance components.**

### \3. What Is AI Governance?

AI Governance refers to the decision-making, responsibility, policy and oversight mechanisms established for the development, use and management of AI systems.

AI Governance is not solely a security matter.

It is also linked to transparency, accountability, data protection, compliance and system reliability.

#### Within the scope of AI Governance

AI usage policies are established.

Responsibilities are defined.

Risks are assessed.

Approval processes are designed.

Suppliers are evaluated.

Performance and security are monitored.

Non-conformities are managed.

#### Example

The human resources department of an organisation wants to use AI for candidate evaluation.

In this case, completing the technical integration alone is not enough.

The conditions for processing personal data, potential discrimination risks, decision-making processes, human oversight and security controls must be assessed together.

This assessment is part of the AI Governance approach.

### \4. What Is ISO/IEC 42001?

ISO/IEC 42001 is the international standard that defines the requirements for an AI management system.

The standard provides a management system framework that enables organisations to manage their use of AI systematically.

ISO/IEC 42001 is not purely a cyber security standard.

It covers the assessment of AI-related risks, opportunities, responsibilities and management processes.

#### Core approach

Determining the organisational context.

Leadership and responsibility.

Planning.

Support processes.

Operation.

Performance evaluation.

Improvement.

This structure follows management principles similar to those of other ISO management system standards.

### \5. Why Is ISO/IEC 42001 Important?

The uncontrolled spread of AI use across different departments can increase corporate risk.

ISO/IEC 42001 helps AI activities to be managed systematically.

#### Corporate benefits

Making AI use visible.

Defining responsibilities.

Structuring risk management.

Establishing policies.

Monitoring controls.

Supporting internal audit processes.

Adopting a continuous improvement approach.

#### An important distinction

ISO/IEC 42001 management system certification does not mean that all AI applications in the organisation are technically secure.

The certification scope and management system conformity are different assessments from the technical security testing of individual systems.

For this reason, ISO/IEC 42001 implementations should be supported by technical security controls.

### \6. The Difference Between ISO/IEC 42001 and ISO/IEC 27001

ISO/IEC 27001 defines the requirements for an information security management system.

ISO/IEC 42001, on the other hand, focuses on the requirements for an AI management system.

| Criterion | ISO/IEC 27001 | ISO/IEC 42001 |
| --- | --- | --- |
| Core focus | Information security management | AI management |
| Risk scope | Information security risks | AI-related risks and opportunities |
| Asset approach | Information and associated assets | AI systems, resources and processes |
| Management system | ISMS (Information Security Management System) | AIMS (AI Management System) |
| Technical security testing | Risk-based supporting activity | Risk-based supporting activity |
| Continuous improvement | Present | Present |

These standards are not alternatives to one another.

An organisation can implement both management systems in an integrated way.

For example, the information security risks of an AI system can be linked to ISO/IEC 27001 processes.

AI-specific management and impact assessments, on the other hand, can be addressed under ISO/IEC 42001.

### \7. What Is NIST AI RMF?

The NIST AI Risk Management Framework is a framework developed to support the management of AI risks.

NIST AI RMF aims to help organisations assess their AI systems in terms of trustworthiness and risk management.

The framework is structured around four core functions.

#### GOVERN

Establishing governance mechanisms for AI risk management.

#### MAP

Identifying the context and risks of the AI system.

#### MEASURE

Assessing risks and system characteristics.

#### MANAGE

Prioritising and managing risks.

These functions should be regarded not as a one-off linear process but as activities that can be used throughout the lifecycle.

### \8. Can NIST AI RMF and ISO/IEC 42001 Be Used Together?

Yes.

The two approaches can complement each other.

ISO/IEC 42001 defines management system requirements.

NIST AI RMF, on the other hand, offers a flexible framework for identifying, measuring and managing AI risks.

#### Example use

An AI risk management process can be defined under ISO/IEC 42001.

NIST AI RMF functions can be used to structure risk assessment activities.

Technical security tests can support the verification of risks.

Management reviews can ensure that the results are evaluated.

This approach helps governance and technical security to be addressed together.

### \9. What Is an AI Security Programme?

An AI Security Programme is the organisational and technical programme that enables the organisation to manage its AI security activities systematically.

It is not always sufficient for this programme to be run by the security team alone.

The participation of different teams may be required.

#### Relevant teams

Senior management.

Information security.

Information technology.

Software development.

Data management.

Legal and compliance.

Risk management.

Human resources.

Business units.

#### Core objectives of the programme

Making AI risks visible.

Defining security responsibilities.

Establishing standard controls.

Carrying out technical security tests.

Managing security incidents.

Ensuring continuous improvement.

### \10. How Is an AI Inventory Built?

One of the first steps of enterprise AI security is identifying the systems in use.

This is because it is difficult to manage the risks of a system that is not in the inventory.

#### Information an inventory may contain

The name of the AI application.

The business owner.

The technical owner.

The purpose of use.

The model provider.

The model type.

Data sources.

The data classes processed.

User groups.

External integrations.

AI Agent capabilities.

The risk level.

#### Sample inventory

| System | Purpose of use | Data type | Sample risk |
| --- | --- | --- | --- |
| AI Code Assistant | Software development | Source code | Leakage of commercial data |
| HR AI Assistant | Human resources | Personal data | Unauthorised access |
| SOC AI Agent | Security operations | Incident logs | Excessive permissions |
| RAG Knowledge Assistant | Corporate knowledge access | Internal documents | Data disclosure |
| Finance AI Analysis | Financial reporting | Financial data | Confidentiality and accuracy |

This table is illustrative.

The real inventory should be prepared according to the organisation's areas of use.

### \11. Shadow AI Inventory

Alongside the officially approved AI applications, there may also be services in uncontrolled use.

This situation is called Shadow AI.

#### Risks

Use of unapproved SaaS.

Transfer of sensitive data.

Access outside corporate accounts.

Lack of auditing.

Unknown data processing conditions.

#### Management approach

Employee needs should be identified.

Approved AI tools should be defined.

Appropriate visibility controls should be applied.

Data protection policies should be established.

Awareness of usage should be raised.

Shadow AI management should not rely solely on a technical blocking approach.

Offering secure alternatives is also important.

### \12. What Is AI Risk Assessment?

AI Risk Assessment is the identification and evaluation of the risks that may arise from the use of an AI system.

These risks are not limited to cyber security.

#### Risk categories

Information security.

Personal data protection.

Model reliability.

Operational continuity.

Supplier dependency.

Legal compliance.

Production of incorrect decisions.

Unauthorised automation.

#### Example

Consider an AI Agent that is integrated with a payment system.

The risk assessment of this system must take into account not only API security but also business impacts such as creating unauthorised payments and carrying out incorrect transactions.

### \13. How Are AI Risks Classified?

Risk classification should be built according to the organisation's risk methodology.

#### Assessment criteria

Sensitivity of the data processed.

Resources the system accesses.

Number of users.

Level of automation.

Impact on business processes.

Attack surface.

Existing security controls.

#### Sample risk levels

**Low Risk:** Applications with limited data and transaction impact, such as general content generation.

**Medium Risk:** Systems that access corporate content but do not carry out critical transactions.

**High Risk:** Applications that process sensitive data or affect important business processes.

**Critical Risk:** Applications that can carry out high-impact transactions in critical systems and could cause serious operational consequences.

These levels are examples.

They should not be regarded as identical to the risk classifications used in legal regulations.

### \14. How Is an AI Security Policy Created?

An AI Security Policy defines the organisation's security rules for the use of AI.

The policy should be aligned with the organisation's business needs and risks.

#### Policy scope

Approved AI services.

User responsibilities.

Data sharing rules.

Model provider assessment.

Access control.

AI Agent authorisation.

Security testing.

Incident reporting processes.

Audit and log management.

#### Key point

The policy should not be published merely as a document.

It should be supported by technical controls and awareness activities.

### \15. What Is Secure AI SDLC?

Secure AI SDLC is the integration of security controls into the development lifecycle of AI systems.

It is similar to the traditional Secure SDLC approach.

However, it also covers AI-specific data, model and behaviour risks.

#### Lifecycle

Requirements analysis.

Architectural design.

Data preparation.

Model selection.

Development.

Security testing.

Deployment.

Monitoring.

Updating.

Retirement and data deletion.

Different security controls should be applied at each stage.

### \16. Secure AI SDLC – Design Phase

Security requirements should be determined during the design phase.

#### Areas of assessment

Purpose of use.

Data classification.

Model selection.

Trust boundaries.

User roles.

Tool permissions.

Supplier requirements.

#### Example

If a customer support AI Agent is being developed, which customer data it can access and which transactions it can carry out should be determined during the design phase.

Making these decisions only after development can lead to security problems.

### \17. Secure AI SDLC – Development Phase

During the development phase, application and integration security are important.

#### Controls

Secure Coding.

API Security.

Dependency Security.

Secret Management.

Input Validation.

Output Validation.

Access Control.

Logging.

#### AI-specific controls

Prompt security.

RAG access control.

Tool Calling authorisation.

Model integration security.

Data minimisation.

These controls can be applied together with traditional DevSecOps processes.

### \18. Secure AI SDLC – Testing Phase

AI systems should undergo risk-based security testing before they are moved to the production environment.

#### Test areas

LLM Pentest.

AI Red Teaming.

Prompt Injection.

Jailbreak.

RAG Security.

AI Agent Security.

MCP Security.

Model Security.

API Security.

#### Test plan

The system's architecture should be assessed.

Critical assets should be identified.

Test scenarios should be created.

Security impacts should be measured.

Findings should be reported.

Remediations should be verified.

### \19. Secure AI SDLC – Deployment Phase

Security controls should be applied when the model or AI application is moved to the production environment.

#### Controls

Approved model version.

Artifact integrity.

Secure configuration.

Authentication.

Authorisation.

Secret Management.

Logging.

Rollback.

#### Key point

The fact that a model behaves securely in the test environment does not mean that the same security conditions will automatically be met in the production environment.

Production environment configurations must be verified separately.

### \20. Secure AI SDLC – Operations Phase

AI systems in the production environment should be monitored continuously.

#### Monitoring areas

Model behaviour.

API usage.

Sensitive data transfers.

Unauthorised access attempts.

Agent tool calls.

Policy violations.

Model updates.

#### Continuous improvement

Security incidents should be analysed.

New risks should be assessed.

Policies should be updated.

Security tests should be repeated.

This approach ensures that AI security does not remain a one-off activity.

### \21. AI Security Architecture

An enterprise AI security architecture can consist of different control layers.

#### Sample architecture

ENTERPRISE AI GOVERNANCE

|

v

AI Risk Management

|

v

AI Security Policy

|

v

Secure AI SDLC

|

+-------------+-------------+

| | |

v v v

AI Gateway AI DLP IAM / PAM

| | |

+-------------+-------------+

|

v

AI Applications

|

+-------------+-------------+

| | |

v v v

LLM RAG AI Agent

| | |

+-------------+-------------+

|

v

AI Security Testing

|

v

SOC / SIEM / SOAR

|

v

Continuous Improvement

This architecture is an example.

The actual implementation should be designed according to the organisation's technical infrastructure and risk level.

### \22. The Role of the AI Gateway in the Enterprise Programme

An AI Gateway can be one of the technical control components of an AI security programme.

#### Areas of use

Model access policies.

Prompt security.

Sensitive data control.

Data masking.

Usage monitoring.

Tool call control.

Audit logs.

However, an AI Gateway does not by itself provide enterprise AI Governance.

Policy, risk management and responsibility processes must be established separately.

### \23. The Role of AI Red Teaming in the Enterprise Programme

AI Red Teaming enables AI systems to be evaluated against realistic attack scenarios.

These exercises should not be carried out only during initial setup.

They should also be reassessed after significant changes.

#### Test triggers

Adoption of a new model.

A new RAG data source.

A new MCP integration.

A new Agent permission.

Connection to a critical system.

A change in security policy.

A major model update.

#### Purpose

To verify the effectiveness of security controls on the real system.

### \24. AI Security Monitoring

Security incidents involving AI systems should be included in corporate monitoring processes.

#### Incident examples

Suspected Prompt Injection.

Attempted sensitive data transfer.

Unauthorised model access.

Abnormal API usage.

Critical Agent action.

MCP integration error.

#### SOC integration

Events can be forwarded to the SIEM system.

Correlation rules can be created.

They can be evaluated by security teams.

Where necessary, incident response processes can be initiated.

However, it is not appropriate to treat every model behaviour as a security incident.

Alert quality and context are important.

### \25. What Is AI Incident Response?

AI Incident Response refers to the processes for responding to security incidents related to AI systems.

#### Incident types

Sensitive data leakage.

Unauthorised Agent action.

Model API key leakage.

RAG data access breach.

Model artifact manipulation.

Supply chain security incident.

#### Response stages

Incident detection.

Initial assessment.

Identification of affected systems.

Isolation where necessary.

Evidence collection.

Root cause analysis.

Remediation.

Post-incident review.

These processes should be linked to the organisation's existing incident response plan.

### \26. An AI Incident Response Scenario

Consider an organisation that uses a RAG-based document assistant.

A user has gained access to document content that they should not normally be able to reach.

#### Initial assessment

The affected user and document are identified.

The scope of the incident is examined.

#### Technical analysis

Retrieval access controls are assessed.

Metadata filters are examined.

Logs are analysed.

#### Response

Necessary access is restricted.

Faulty configurations are corrected.

#### Remediation

RAG authorisation tests are carried out.

Similar data sources are assessed.

#### Post-incident

The root cause and the measures taken are reported.

This example shows that AI Incident Response processes can be applied together with traditional incident response methods.

### \27. AI Supplier Security

Third-party providers can play an important role in enterprise AI systems.

#### Supplier assessment areas

Data processing conditions.

Data retention periods.

Data residency.

Sub-processors.

Use of data for model training.

Security controls.

Incident notification processes.

Access management.

Contractual obligations.

#### Key point

A provider holding a security certification does not mean that it automatically meets all of the organisation's data processing and security requirements.

The actual service scope and contract terms must be assessed separately.

### \28. KVKK (Turkish Personal Data Protection Law) and AI Security

AI systems can process personal data.

In this case, the relevant personal data protection obligations must be assessed.

#### Key areas

Conditions for processing.

Obligation to inform.

Data minimisation.

Purpose limitation.

Retention period.

Data security.

Transfer of data abroad.

Data subject rights.

#### Example

If an organisation sends its employees' personal data to an external AI service, the conditions for data processing and transfer must be assessed.

Using an AI service does not remove personal data protection obligations.

### \29. GDPR and AI

The European Union General Data Protection Regulation is important for personal data processing activities within its scope.

AI systems can process personal data covered by the GDPR.

#### Areas of assessment

Lawful processing.

Transparency.

Data minimisation.

Data security.

Data subject rights.

Automated decision-making.

Data transfer.

#### An important distinction

Not every AI application is subject to the same GDPR obligations.

The requirements depend on the nature of the data processing activity and the relevant legal conditions.

### \30. The EU AI Act and Enterprise AI Management

The European Union Artificial Intelligence Act is a regulation that sets out risk-based obligations for certain AI systems and actors.

Under the regulation, the intended purpose of the system, the role of the actor concerned and the applicable provisions are important.

#### Areas of corporate assessment

The intended purpose of the AI system.

Risk classification.

Position as provider or deployer.

Transparency obligations.

Human oversight.

Technical documentation.

Risk management.

#### Key point

EU AI Act obligations are not the same for all systems.

In addition, provisions may start to apply on different dates, and changes to the entry-into-force timetable must be taken into account.

For this reason, for AI projects aimed at the European market, the current legislation and transitional provisions should be assessed separately.

### \31. ISO/IEC 42001 and Technical Security Controls

The management processes established under ISO/IEC 42001 can be supported by technical security activities.

#### Sample mapping

| Management need | Technical activity |
| --- | --- |
| AI inventory | Model and application discovery |
| Risk assessment | AI Threat Modeling |
| Data security | AI DLP and access control |
| Secure development | Secure AI SDLC |
| Technical verification | LLM Pentest and AI Red Teaming |
| Operational monitoring | SIEM and security monitoring |
| Continuous improvement | Retest and control updates |

This table is a sample mapping.

It does not replace a formal conformity assessment against the clauses of the standard.

### \32. AI Security KPIs and KRIs

It is important that an enterprise AI security programme is measurable.

KPI and KRI indicators can be used for this purpose.

KPI is the abbreviation of Key Performance Indicator.

KRI, on the other hand, stands for Key Risk Indicator.

#### Sample KPI indicators

Proportion of AI systems included in the inventory.

Proportion of systems whose risk assessment has been completed.

Proportion of applications for which security testing has been carried out.

Proportion of security findings that have been closed.

#### Sample KRI indicators

Use of unapproved AI services.

Number of high-risk vulnerabilities.

Attempted sensitive data transfers.

Number of over-privileged AI Agents.

Gaps in critical security controls.

These indicators should be determined according to the organisation's risk profile.

### \33. AI Security Maturity Model

Enterprise AI security maturity can be assessed in stages.

#### Level 1: Initial

AI use has limited visibility.

Policies and inventory may be missing.

#### Level 2: Basic Control

An AI inventory is created.

Basic usage policies are applied.

#### Level 3: Managed

Risk assessments are carried out.

Security tests are planned.

Access and data protection controls are applied.

#### Level 4: Measured

Security indicators are monitored.

Continuous testing is carried out.

Incidents are evaluated centrally.

#### Level 5: Optimised

Risk management and security controls are continuously improved.

Automation and governance processes work in an integrated way.

This model is an example maturity approach; it is not an official ISO/IEC 42001 level classification.

### \34. Enterprise AI Security Roadmap

An AI security programme can be built in stages.

#### Phase 1: Current State Analysis

The AI systems in use are identified.

Existing policies are reviewed.

Data flows are assessed.

#### Phase 2: Risk Assessment

Critical AI applications are identified.

Threat modelling is carried out.

Risks are prioritised.

#### Phase 3: Policy and Governance

The AI Security Policy is created.

Responsibilities are defined.

Approval processes are determined.

#### Phase 4: Technical Controls

AI Gateway.

DLP.

IAM.

Agent authorisation.

Logging.

Monitoring.

and similar controls are implemented as needed.

#### Phase 5: Security Testing

LLM Pentest.

AI Red Teaming.

RAG Security Testing.

Agent Security Testing.

and similar activities are carried out.

#### Phase 6: Continuous Monitoring

Security incidents are monitored.

Risks are reassessed.

Controls are improved.

### \35. The First 90-Day AI Security Plan

A sample 90-day approach can be applied by organisations that want to build an enterprise AI security programme.

#### First 30 Days: Visibility and Inventory

AI areas of use are identified.

Model providers are added to the inventory.

Shadow AI risks are assessed.

Critical data flows are examined.

#### Days 31–60: Risk and Policy

Risk assessments are carried out.

The AI Security Policy is prepared.

An authorisation matrix is created.

Priority technical controls are determined.

#### Days 61–90: Implementation and Verification

Priority security controls are implemented.

Security tests are carried out on critical systems.

Monitoring processes are established.

An improvement plan is prepared.

These timeframes are examples.

They may vary depending on the size of the organisation, the number of systems and the level of maturity.

### \36. Enterprise AI Security RACI Matrix

The RACI approach can help define responsibilities for activities.

R: Responsible – the party that carries out the work.

A: Accountable – the party with final accountability.

C: Consulted – the party whose opinion is sought.

I: Informed – the party that is kept informed.

#### Example

| Activity | Business Unit | Information Security | IT / Software | Senior Management |
| --- | --- | --- | --- | --- |
| AI inventory | R | C | R | I |
| Risk assessment | C | A/R | C | I |
| Technical security controls | C | A | R | I |
| Security testing | I | A/R | C | I |
| Policy approval | C | R | C | A |
| Critical risk acceptance | C | R | C | A |

This matrix is an example.

The actual distribution of responsibilities should be determined according to the organisation's structure.

### \37. The SECURESYS Approach to Enterprise AI Security

At SECURESYS, we do not assess AI security solely through individual security products or testing activities.

This is because enterprise AI security requires governance, data protection, software security, model security and operational monitoring processes to be addressed together.

For this reason, it is important for organisations to adopt an integrated approach in their AI security work.

#### AI Governance and Risk Management

Taking an inventory of AI systems.

Assessing risks.

Defining policies and responsibilities.

#### ISO/IEC 42001 Consultancy

Assessing the requirements of an AI management system.

Current state analysis.

Process and control design.

Improvement plan.

#### Secure AI SDLC

Integrating security controls into the AI development lifecycle.

#### AI Red Teaming and LLM Pentest

Prompt Injection.

Jailbreak.

RAG Security.

AI Agent Security.

MCP Security.

Model and integration security.

#### AI Gateway and Data Security

Assessing the need for central control in enterprise AI use.

Sensitive data protection.

Prompt security.

Agent and tool permissions.

#### SOC and Security Monitoring

Monitoring AI security incidents.

SIEM integrations.

Supporting incident response processes.

#### Bastiyon AI Gateway

A solution approach for the central policy, data protection and audit needs within an enterprise AI security architecture.

The scope of this work should be determined according to the organisation's infrastructure, risk level and needs.

**In enterprise AI security, the core goal is not merely to reduce vulnerabilities but to turn AI use into a sustainable and auditable management model.**

### \38. Enterprise AI Security Checklist

#### Governance

- Has an AI usage policy been established?
- Have AI Governance responsibilities been defined?
- Have AI systems been added to the inventory?
- Has a risk assessment process been defined?

#### Data security

- Has data classification been carried out?
- Are sensitive data transfers being controlled?
- Have the conditions for processing personal data been assessed?
- Have data retention policies been established?

#### Technical security

- Is Secure AI SDLC being applied?
- Is LLM Pentest being carried out?
- Have RAG access controls been assessed?
- Have AI Agent permissions been restricted?
- Are MCP integrations being checked?

#### Operational security

- Are security incidents being monitored?
- Is there an AI Incident Response process?
- Is retesting carried out on critical systems?
- Are model and integration changes being checked?

#### Management system

- Have the ISO/IEC 42001 requirements been assessed?
- Has the NIST AI RMF approach been reviewed?
- Have security indicators been defined?
- Has a continuous improvement process been established?

### Frequently Asked Questions

#### What is enterprise AI security?

It is an organisation's management of the security risks of the AI systems it develops or uses through technical, administrative and operational controls.

#### What is AI Governance?

It is the set of policy, responsibility and oversight mechanisms established for the responsible development and use of AI systems.

#### What is ISO/IEC 42001?

It is the international standard that defines the requirements for an AI management system.

#### Does an ISO/IEC 42001 certificate guarantee that AI systems are secure?

No. Management system conformity and the technical security of individual AI applications are different assessments.

#### What is NIST AI RMF?

It is a framework that supports the management of AI risks and is structured around the GOVERN, MAP, MEASURE and MANAGE functions.

#### Can ISO/IEC 42001 and NIST AI RMF be used together?

Yes. The management system and risk management approaches can complement each other.

#### What is Secure AI SDLC?

It is the integration of security controls into the AI development lifecycle.

#### What is AI Risk Assessment?

It is the assessment of the security, data protection, operational and other relevant risks of AI systems.

#### What is an AI Security Policy?

It is the policy that defines the organisation's security rules and responsibilities for AI use.

#### Why is AI Red Teaming necessary?

It helps verify the security boundaries of AI systems against realistic attack scenarios.

#### Is an AI Gateway mandatory for enterprise AI security?

It is not mandatory for every organisation. It is one of the technical control options that should be assessed according to need, architecture and risk level.

#### How is Shadow AI managed?

It can be managed through inventory, visibility, policy, employee awareness and appropriate technical controls.

#### What is AI Incident Response?

It is the process of detecting, analysing, responding to and remediating security incidents related to AI systems.

#### How often should AI security be assessed?

It should be determined according to the organisation's risk level and system changes. Reassessment after critical changes is important.

#### How many days does it take to build an enterprise AI security programme?

The duration depends on the size of the organisation, the number of systems and the current level of maturity. A sample 90-day roadmap can be used for the initial inventory and priority controls.

### Conclusion: AI Security Must Become an Enterprise Capability

AI technologies are increasingly used in organisations' business processes.

Large language models make access to information easier.

RAG systems draw on corporate documents.

AI Agent technologies increase automation.

AI-assisted software development tools support productivity.

However, these systems create new security risks.

Prompt Injection attacks can affect model behaviour.

Unauthorised data access can occur in RAG systems.

AI Agents may hold overly broad permissions.

The model supply chain may harbour security problems.

Sensitive data may be transferred to uncontrolled AI services.

For this reason, it is not sufficient to manage AI security only with individual products or periodic tests.

Organisations need to build sustainable security programmes.

AI systems should be added to the inventory.

Risks should be assessed.

Policies should be established.

Responsibilities should be defined.

Secure AI SDLC should be applied.

Technical security controls should be put in place.

AI Red Teaming and LLM Pentest work should be carried out.

Security incidents should be monitored.

And all of these processes should be continuously improved.

ISO/IEC 42001, NIST AI RMF and other relevant frameworks can help structure this work.

But the real success is not merely achieving compliance with standards.

It is making AI security part of the organisation's day-to-day way of working.

**Secure AI is made possible by the combined application of the right technology, the right governance, the right security controls and continuous verification processes.**

### Software and AI Security Series – Overall Review

In this 12-part series, we examined the security risks of modern AI systems from different angles.

**Part 1:** What Is Software and AI Security?

**Part 2:** Security Risks of Developing Software with AI.

**Part 3:** LLM Security and Cyber Attacks Against Large Language Models.

**Part 4:** Prompt Injection and Jailbreak Attacks.

**Part 5:** AI Agent Security, Tool Calling and MCP Risks.

**Part 6:** RAG Security, Vector Databases and Document Poisoning.

**Part 7:** Shadow AI, KVKK, GDPR and Sensitive Data Protection.

**Part 8:** AI Model Security, Data Poisoning and Model Theft.

**Part 9:** MLOps and AI Supply Chain Security.

**Part 10:** AI Red Teaming and LLM Pentest.

**Part 11:** AI Gateway, Prompt Firewall, DLP and Agent Control.

**Part 12:** Enterprise AI Security Programme, ISO/IEC 42001 and NIST AI RMF.

The central message of this series is clear:

**AI security is not model security alone.**

It is data security.

It is software security.

It is identity and access management.

It is supply chain security.

It is operational security.

It is risk management.

And it is corporate governance.

#### SECURESYS Knowledge Base

**AI Security | Application Security | AI Red Teaming | LLM Pentest | Secure AI SDLC | ISO/IEC 42001 | SOC | Cyber Security Consultancy**

**Secure AI, Secure Future.**