AI Development Life Cycle Security Touchpoints

1. Why This Topic Matters

Security problems in AI systems are rarely created at the moment of deployment. They are introduced much earlier: a biased or poisoned dataset, an unvetted pre-trained model pulled from a public repository, a training pipeline with weak access controls, or an inference API with no input validation. By the time these weaknesses surface in production, remediation is expensive, disruptive and sometimes impossible without full retraining.

ISACA's Advanced in AI Security Management (AAISM) certification therefore emphasises security touchpoints – specific, planned points in the AI development life cycle where security activities, reviews, and controls must be applied. This is the AI-specific version of the long-standing principle of shifting security left and building security by design, extended to cover data, models and machine learning pipelines rather than just application code.

For the exam, this topic matters because:
• It sits squarely in Domain 3 (AI Technologies and Controls) and links to Domain 2 (AI Risk Management) and Domain 1 (AI Governance).
• Many scenario questions describe an incident and ask at which phase a control should have been applied, or which control is most effective at a given phase.
• ISACA expects candidates to think like an AI security manager – prioritising preventive, early-phase, risk-based controls over reactive technical fixes.

2. What Are AI Development Life Cycle Security Touchpoints?

A security touchpoint is a defined intersection between a life-cycle phase and a security activity. It answers the question: at this stage, what must security do, verify, or approve before the project moves on?

The AI development life cycle used in AAISM materials (consistent with the NIST AI RMF, ISO/IEC 42001, and the OECD framework) is generally described in these phases:

1. Planning and Design (problem definition, use-case approval, requirements)
2. Data Collection and Preparation (sourcing, labelling, cleaning, feature engineering)
3. Model Development and Training (algorithm selection, training, tuning, use of foundation models)
4. Validation and Testing (evaluation, adversarial testing, fairness testing, acceptance)
5. Deployment (integration, release, configuration, hardening)
6. Operation and Monitoring (performance, drift, abuse detection, incident response)
7. Retirement and Decommissioning (secure disposal of models and data)

Security touchpoints exist in every phase, and several controls are cross-cutting – they apply throughout (documentation, access control, logging, change management, third-party/supply chain oversight and human oversight).

3. How It Works: Touchpoints Phase by Phase

Phase 1 – Planning and Design
Key security touchpoints:
• Use-case risk classification – determine the risk tier (for example, high-risk under the EU AI Act) which drives the depth of all later controls.
• AI threat modelling – apply STRIDE or MITRE ATLAS to identify threats such as data poisoning, model evasion, model extraction, prompt injection and inference attacks.
• Security and privacy requirements – define confidentiality, integrity, availability, robustness, explainability and privacy requirements as acceptance criteria.
• Privacy Impact Assessment (PIA/DPIA) and legal/regulatory mapping.
• Roles and accountability – assign ownership (data owner, model owner, security lead) and define the approval gates.
• Build-vs-buy decision and vendor due diligence if third-party models or platforms will be used.
Exam angle: This is the most cost-effective phase to address risk. If a question asks where a control is best introduced to prevent a design-level flaw, the answer is almost always planning/design.

Phase 2 – Data Collection and Preparation
Key security touchpoints:
• Data provenance and lineage – know where data came from, who touched it, and whether it was legally obtained with appropriate consent or licence.
• Data classification and access control – apply least privilege to raw and processed datasets.
• Integrity controls – hashing, versioning and signing of datasets to detect tampering and data poisoning.
• Data quality and bias assessment – representativeness checks, outlier detection, label quality review.
• Privacy-enhancing techniques – anonymisation, pseudonymisation, differential privacy, synthetic data, data minimisation.
• Secure storage and retention – encryption at rest, defined retention and deletion schedules.
• Datasheets for datasets – documented characteristics, limitations and intended use.
Exam angle: Data poisoning and privacy leakage questions usually point to controls in this phase (provenance validation, integrity checks, access control), not to deployment-time filtering.

Phase 3 – Model Development and Training
Key security touchpoints:
• Secure development environment – segregated, access-controlled training environments; secrets management; secured notebooks.
• Supply chain security – vet pre-trained models, libraries and frameworks; maintain an AI Bill of Materials (AI-BOM) covering models, datasets and dependencies; scan for vulnerabilities and malicious serialised objects (e.g., unsafe pickle files).
• Model provenance and versioning – model registry, experiment tracking, reproducibility.
• Secure MLOps pipeline – CI/CD controls, code review, signed artefacts, protection against pipeline tampering.
• Robustness techniques – adversarial training, regularisation, differential privacy in training where required.
• Protection of model intellectual property – encryption and access control for weights and parameters.
Exam angle: Questions about an open-source model containing a backdoor or an insecure library are supply-chain questions; the answer involves pre-use vetting, AI-BOM and provenance verification at the development phase.

Phase 4 – Validation and Testing
Key security touchpoints:
• Adversarial testing and AI red teaming – evasion, prompt injection, jailbreaks, model extraction, membership inference, data leakage.
• Robustness and stress testing – performance under distribution shift, noisy or malicious inputs.
• Fairness and bias testing against defined metrics.
• Explainability and transparency validation.
• Security testing of surrounding components – APIs, orchestration layers, plug-ins, retrieval sources (RAG).
• Independent review and formal acceptance – compare results against the acceptance criteria defined in Phase 1; document residual risk and obtain risk acceptance from the business owner.
• Model card – documented purpose, performance, limitations, evaluation results.
Exam angle: Validation is the gate before deployment. If a question describes a model going live without adversarial testing or acceptance sign-off, the control failure is here. Note that testing detects problems; it does not replace preventive design controls.

Phase 5 – Deployment
Key security touchpoints:
• Secure configuration and hardening of the serving infrastructure, containers and endpoints.
• Authentication, authorisation and rate limiting on inference APIs (mitigates model extraction and denial-of-service).
• Input validation and output filtering / guardrails – content filters, prompt injection defences, PII redaction.
• Model integrity verification – signed models, hash checks at load time, protection against model swapping.
• Environment segregation – development, test and production separation; no training data in production unless required.
• Change management and release approval – documented, authorised releases; rollback capability.
• Human-in-the-loop controls where the risk tier requires human oversight of decisions.
Exam angle: Deployment controls are largely detective and preventive at run time. They are essential but are the wrong answer when the question asks how to prevent a flaw that originated in data or design.

Phase 6 – Operation and Monitoring
Key security touchpoints:
• Performance and drift monitoring – data drift, concept drift, accuracy degradation, with defined thresholds and retraining triggers.
• Security monitoring – anomalous query patterns (extraction attempts), abuse, jailbreak attempts, unusual confidence distributions.
• Logging and audit trails – inputs, outputs, decisions and model version for accountability and forensics (balanced against privacy).
• Vulnerability and patch management for frameworks, libraries and infrastructure.
• AI incident response plan – playbooks for poisoning, leakage, harmful outputs; escalation and disclosure procedures.
• Feedback loop security – controls over user feedback or online learning to prevent poisoning in production.
• Periodic reassessment – re-run risk assessments and compliance checks when the model, data or regulations change.
Exam angle: Questions mentioning degradation over time, changing input patterns or unexpected outputs after months in production point to drift monitoring and retraining governance.

Phase 7 – Retirement and Decommissioning
Key security touchpoints:
• Secure deletion or archival of models, weights, embeddings and training data in line with retention policy and legal hold requirements.
• Dependency and consumer notification – downstream systems and users informed and migrated.
• Revocation of credentials, API keys and access rights.
• Documentation of decommissioning for audit and regulatory evidence.
Exam angle: Often overlooked; a model that is no longer maintained but still exposed is an attack surface. Retirement must be a planned, governed activity.

4. Cross-Cutting Principles to Remember

• Shift left / security by design: the earlier a control is applied, the cheaper and more effective it is.
• Defence in depth: no single touchpoint is sufficient; controls at every phase complement each other.
• Risk-based proportionality: the depth of each touchpoint should scale with the AI system's risk classification.
• Gates and accountability: each phase should end with a documented review and approval by an accountable owner.
• Traceability: provenance of data, models and decisions must be documented end-to-end (datasheets, model cards, AI-BOM, registries).
• Continuous life cycle: monitoring findings feed back into design, data and retraining – it is a loop, not a straight line.
• Integration with existing SDLC/DevSecOps: AI touchpoints should extend, not replace, the organisation's secure development framework.

5. Common Threats Mapped to Their Primary Touchpoint

• Data poisoning → Data phase (provenance, integrity, access control) and Operation phase (feedback loop controls).
• Model supply chain compromise → Development phase (vetting, AI-BOM, signing).
• Evasion / adversarial examples → Development (adversarial training) and Validation (red teaming).
• Prompt injection / jailbreaks → Validation (testing) and Deployment (input/output guardrails).
• Model extraction / theft → Deployment (authentication, rate limiting) and Operation (query anomaly monitoring).
• Membership inference / privacy leakage → Data phase (privacy-enhancing techniques) and Validation (privacy testing).
• Drift and silent degradation → Operation (monitoring, retraining triggers).
• Orphaned or unmaintained models → Retirement (decommissioning governance).

6. Exam Tips: Answering Questions on AI Development Life Cycle Security Touchpoints

Tip 1 – Identify the phase first. Read the scenario and decide which life-cycle phase the problem originated in. ISACA questions frequently reward the answer that addresses the root phase rather than the phase where the symptom appeared.

Tip 2 – Earliest effective control usually wins. When two options would both work, prefer the one applied earlier in the life cycle (design or data phase). Prevention at design beats detection at deployment, which beats correction in operation.

Tip 3 – Think like a manager, not an engineer. AAISM is a management certification. If an option describes a governance action (define acceptance criteria, establish approval gates, assign accountability, classify risk) and another describes a purely technical tweak, the management option is often the best answer unless the question explicitly asks for a technical control.

Tip 4 – Watch for the qualifier words. Most important, best, first, primary and most effective signal that several options are plausible. First usually points to assessment, classification or requirements definition. Most effective for prevention usually points to design or data controls. Most effective for detection points to validation or monitoring.

Tip 5 – Separate detective from preventive. Testing, red teaming, and monitoring detect problems. Threat modelling, secure requirements, data integrity controls and supply-chain vetting prevent them. Match the control type to what the question asks.

Tip 6 – Supply chain scenarios. Any mention of open-source models, third-party datasets, external APIs or pre-trained foundation models signals supply-chain touchpoints: due diligence, provenance verification, AI-BOM, licence review and integrity checks before use.

Tip 7 – Drift and time. If the scenario says the model worked at launch but behaves differently now, the answer involves monitoring for drift, defined thresholds, and governed retraining – not redoing threat modelling from scratch.

Tip 8 – Do not forget retirement. Questions about legacy models, unused endpoints or data that should have been deleted are testing decommissioning controls.

Tip 9 – Acceptance and sign-off. When a scenario involves a model deployed without meeting criteria, the missing control is typically a formal validation gate with documented risk acceptance by the business owner – not simply more testing.

Tip 10 – Eliminate extremes. Options that say stop all AI development, rely solely on the vendor, or test only in production are almost never correct. ISACA favours balanced, risk-based, documented and repeatable approaches.

7. Worked Example

Scenario: An organisation deployed a customer-service chatbot built on a third-party foundation model. Three months later, users discover it can be manipulated into revealing internal policy documents used during fine-tuning. Which action would have been MOST effective in preventing this?

A. Implementing rate limiting on the inference API
B. Conducting adversarial testing for data leakage before deployment
C. Applying data classification and minimisation to the fine-tuning dataset
D. Monitoring production logs for sensitive content in outputs

Analysis: Option A addresses extraction volume, not leakage of memorised content. Option D is detective, after the fact. Option B would likely have detected the issue, but the question asks what would prevent it. Option C removes or protects the sensitive content before it ever enters the model – the earliest, preventive, root-cause control. Answer: C. Note how the exam rewards the data-phase control over the deployment and operations controls.

8. Quick Revision Summary

• Planning: risk tier, threat model, requirements, PIA, accountability.
• Data: provenance, integrity, classification, privacy techniques, bias checks.
• Development: secure environment, supply chain/AI-BOM, versioning, secure MLOps.
• Validation: red teaming, robustness, fairness, acceptance gate, model card.
• Deployment: hardening, authN/authZ, rate limits, guardrails, integrity, change management.
• Operation: drift and abuse monitoring, logging, patching, incident response, reassessment.
• Retirement: secure deletion, access revocation, notification, documentation.
• Across all: shift left, defence in depth, risk-based proportionality, traceability, governance gates.

Master the mapping of threats to phases and the preference for early, preventive, risk-based, management-level controls, and you will handle the majority of AAISM questions on this topic with confidence.