Frequently Asked Questions

GAISSF is the Global AI Security & Safety Framework. It is a structured framework for governing, securing, assessing and operating AI systems across the lifecycle. It combines governance, model and data integrity, adversarial resilience, secure architecture, deployment, privacy, human oversight, societal harm, assurance and physical-AI safety.

ODA3 Institute publishes GAISSF as the market-facing standards and assurance initiative. ODA3 Pvt Ltd is the legal entity used for copyright, contracting and other formal legal purposes.

Its purpose is to provide a common, evidence-driven baseline for managing AI security and safety risks. It is designed to support implementation, internal assurance, external assessment, customer assurance, regulatory readiness and structured certification programs.

No. GAISSF is a privately developed framework. It may help organizations structure controls and evidence relevant to legal or regulatory obligations, but it does not create law and does not determine whether a legal obligation applies.

GAISSF is structured and governed as a standards-based framework. Its normative documents define requirements, controlled terminology, source governance, release status and change history. Whether a particular jurisdiction or regulator formally recognizes it is a separate question.

GAISSF v1.0 contains 59 controls across nine domains. The control identifiers and exact records are maintained in GAISSF-NOR-001 and GAISSF-NOR-004.

The nine domains address model and data integrity, adversarial robustness, secure architecture and supply chain, secure development and deployment, data protection and privacy, governance and incident management, transparency and human factors, risk and assurance, and physical-AI safety. The controlled domain names in the normative documents should be used for formal references.

No. It applies to generative AI, predictive models, classical machine learning, agentic systems, embedded AI, decision-support systems, AI-enabled software and physical-AI systems. Applicability depends on the system and risk context.

Yes. Smaller organizations may tailor governance structures, staffing and tooling, but they should not dilute applicable control outcomes. Proportional implementation is acceptable; unsupported omission is not.

Yes. The framework is designed for cross-jurisdictional use. Organizations must still identify and comply with local legal, regulatory, contractual and sector-specific obligations.

GAISSF-NOR-001 is the authoritative normative framework standard. GAISSF-NOR-004 is the detailed control catalogue. Implementation guides explain how to adopt and operate the framework but do not override the normative documents.

GAISSF-NOR-002 provides a concise executive interpretation. It is intended for leadership, customers, partners and decision-makers who need the purpose, structure and adoption implications without reading every control record.

GAISSF-NOR-003 gives an initial implementation sequence. It helps organizations begin inventory, scope, ownership, gap assessment and evidence collection without treating the quick-start sequence as a substitute for the full framework.

GAISSF-NOR-005 controls terminology and abbreviations used across the ecosystem. Formal publications, assessments and certification materials should use those terms consistently.

GAISSF-NOR-006 controls reference identifiers, source classes and citation practices. It improves transparency without claiming endorsement or equivalence with external standards.

Release Notes communicate what changed in a release and what users must do. The Change Log preserves historical traceability, decision records, corrections, supersession and the rationale behind material changes.

The implementation documents translate the normative framework into adoption plans, operating procedures, architecture patterns, deployment gates, migration methods, operational workflows and common answers. They are informative unless a contract or certification scheme gives them additional status.

Apply the document hierarchy. GAISSF-NOR-001 and the exact control catalogue prevail over implementation guidance. The issue should be recorded through change governance rather than resolved informally.

Organizations may create internal control narratives, but they should preserve a direct traceability link to the exact GAISSF control identifier and requirement. Internal wording should not silently narrow the original requirement.

Only if they are explicitly identified as current. Superseded drafts, especially incorrect control-count versions, should not be used for implementation, assessment, certification, tooling or public claims.

GAISSF uses staged profiles to support adoption and assurance. The principal profiles are Foundational, Operational and Optimized, with sector or jurisdiction overlays added where applicable.

The controlled Foundational profile contains 52 of the 59 controls. The seven exclusions are defined by the controlled conformance profile and are not equivalent to excluding the entire D9 domain.

Not as a blanket rule. The Foundational profile spans all nine domains. Applicability must be determined from the controlled profile and the system scope, not from an assumption that D9 is automatically excluded.

The Operational profile covers all 59 controls. It is intended for organizations operating the full control baseline with consistent evidence and recurring assurance.

The Optimized profile covers all 59 controls and adds advanced continuous-monitoring, assurance, integration and improvement expectations. It is not simply a higher score; it represents a more mature and continuously verified operating model.

No. Applicability should be based on the selected profile, system scope and controlled exceptions process. Convenience, cost or lack of ownership is not a sufficient reason to omit a control.

It is the controlled record showing which controls apply, which do not, the reason for each decision, the current implementation status, ownership, evidence and any approved exceptions.

Scope should identify legal entities, business units, AI systems, models, data, interfaces, suppliers, users, geographies, lifecycle stages, physical components and the intended assessment or certification boundary.

Yes. An enterprise may have different product, service, platform, regional or business-unit scopes. Each scope should be explicit and should not be represented as enterprise-wide unless it genuinely is.

They remain inside the risk and control model even when the organization cannot inspect the provider’s internals. The organization should document inherited controls, contractual protections, evidence limitations, monitoring and fallback or exit arrangements.

No. Sector, product or jurisdiction profiles should be additive overlays unless the controlled profile explicitly states otherwise.

Yes, but only where the profile and scope support that conclusion. The rationale should be specific, approved, reviewable and reconsidered when the system or operating context changes.

Start with executive sponsorship, an AI-system inventory, a clear scope, selection of the intended profile, assignment of control owners and a baseline assessment. GAISSF-IMP-009 provides the full adoption method.

A senior executive with authority over cross-functional participation, risk acceptance, funding and scope. In larger organizations, board or risk-committee oversight may also be appropriate.

Security, AI engineering, MLOps, architecture, data, privacy, legal, compliance, procurement, supplier management, product, safety, operations, internal audit and executive risk owners may all be relevant.

There is no universal duration. Time depends on scope, maturity, system criticality, existing controls, evidence history, supplier dependence and remediation complexity. Fixed-duration promises should be treated cautiously.

Yes. A phased approach is recommended where scope is large. The organization may begin with governance and shared controls, then add AI-engineering, safety, assurance and certification-readiness workstreams.

Usually no. It should first establish stable operations, ownership, evidence and remediation. Beginning with a certificate deadline often produces paper compliance and weak control operation.

Yes, where they have adequate scope and authority. Existing risk committees, security operations, internal audit, quality management and privacy governance can be extended rather than duplicated.

Typical failures include treating GAISSF as a checklist, copying control text into policy without implementation, under-scoping suppliers and interfaces, relying on self-attestation, collecting evidence only before audit, and confusing maturity with conformance.

No. GAISSF is technology- and vendor-neutral. The implementation should achieve the required control outcomes and produce sufficient evidence.

No. An AI gateway is a useful pattern for centralized policy, routing, logging and supplier control, but other architectures may satisfy the same outcomes.

No. A tool may implement part of a control, but conformance also depends on scope, ownership, configuration, workflow, evidence, testing, monitoring and operating effectiveness.

Document each transition between users, applications, models, tools, data stores, suppliers, assurance services and physical actions. Record assets, identities, permitted flows, controls, telemetry, failure modes and ownership.

Use a controlled registry or equivalent mechanism that records provider, model name, version, configuration, approval status, evaluation baseline and deployment history.

Treat them as controlled configuration. Version them, review changes, test them, restrict production modification and link them to release evidence.

Apply authorization before retrieval, protect tenant isolation, validate source provenance, detect poisoned or malicious content, manage freshness, constrain context and retain source-to-output traceability.

Use approved-provider records, data-minimization rules, contractual controls, service monitoring, model-change detection, response validation, fallback arrangements and documented evidence limitations.

Use signed model packages, secure boot, local policy enforcement, protected local telemetry, authenticated updates, rollback and clearly defined degraded-operation behavior.

GAISSF-IMP-013 provides complete reference patterns for AI gateways, RAG, agentic AI, private-model platforms, external model services, edge AI and physical-AI systems.

Agentic AI can plan, maintain state, call tools, delegate tasks and take actions over time. That creates additional risks around authority, persistence, transactions, memory, looping, delegation and containment.

Permissions should be scoped by identity, objective, tool, action type, resource, transaction value, destination, time and delegation rights.

Shared unrestricted credentials should be avoided. Per-agent or per-service identity improves attribution, least privilege, monitoring and revocation.

Human approval should be required where actions are consequential, irreversible, high-value, safety-relevant, legally significant or outside well-tested automated boundaries.

Memory should have explicit scope, ownership, retention, separation, integrity checks, deletion, contamination controls and evidence of access and modification.

Use step limits, timeouts, rate limits, transaction ceilings, circuit breakers, credential revocation, sandboxing, kill switches and state rollback.

At minimum, identity, user or sponsoring service, goal, plan steps, tool calls, parameters, approvals, memory changes, outputs, errors, state transitions and containment actions.

GAISSF does not impose a universal prohibition. The permitted level of autonomy should be justified by risk, testing, safety, legal obligations, monitoring and available override or containment.

Physical AI is AI that perceives, controls or materially influences physical environments, devices, machinery, vehicles, robots or actuators.

No. GAISSF complements but does not replace sector-specific functional-safety, machinery, automotive, medical-device or other engineering standards.

A safe state is a defined condition that limits or prevents harm when normal operation cannot continue. The appropriate safe state depends on the system and environment.

Where practicable, critical constraints should be enforced by deterministic or independently assured mechanisms rather than relying solely on the learned component being constrained.

Override should be accessible, reliable, independent where necessary, regularly tested, documented and capable of placing the system into a controlled state.

Typical evidence includes hazard analysis, operational envelopes, simulation, hardware-in-the-loop tests, sensor and actuator validation, safe-state exercises, override tests, command logs, near-miss records and incident reconstruction data.

Near misses should be recorded and investigated because they reveal control weaknesses before harm occurs. They should feed corrective action and safety-case updates.

No. Certification may provide evidence of framework conformance within a defined scope, but it cannot replace product approval, specialist engineering judgement or sector safety certification.

Evidence may include policies, architecture, configuration, logs, approvals, test reports, evaluation outputs, tickets, incident records, supplier records, training, metrics, risk decisions and independent-assurance results.

Usually not. A policy shows design intent. Most controls also require implementation, recurring operation and evidence that the mechanism is effective.

Strong evidence is attributable, current, complete, scope-aligned, protected, reproducible where relevant, linked to the exact control and honest about limitations.

Yes, but screenshots alone are often weak. They should identify the system, date, scope, source and relevant configuration, and should be supported by stronger machine-generated or controlled records where possible.

Retention depends on legal, contractual, certification, incident and organizational requirements. GAISSF does not prescribe one universal retention period.

Yes. Failed, negative and inconclusive results are important evidence. Removing them can misrepresent assurance and obstruct root-cause analysis.

Operating effectiveness means the control actually functions consistently in the assessed scope and period, not merely that it is designed or deployed.

Assessment evaluates conformance or readiness. Certification is a formal decision under a defined certification scheme and scope. Not every assessment results in certification.

Yes, after verifying scope, currency, integrity and coverage. Reuse should not be based only on the fact that evidence was accepted in another audit.

Automation can improve consistency and coverage, but it cannot fully replace contextual judgement, interviews, design review, physical observation or evaluation of conflicting evidence.

A VTS defines how a control or control outcome should be tested, what inputs are required, what evidence is produced and how results are interpreted. It supports repeatability but does not eliminate professional judgement.

Use controlled repositories, access restrictions, versioning, timestamps, hashes, signatures, immutable logging or chain-of-custody procedures according to risk.

No. Certification requires an approved scheme, defined scope, competent assessment, decision governance and compliance with mark and claims rules.

It should mean only what the applicable certification scheme states for the named scope, profile, version and period. It should not be represented as a guarantee of safety, security, legality or future performance.

Only if the assessed and certified scope genuinely covers the entire enterprise. Otherwise, claims must identify the specific product, service, platform, business unit or system.

It may describe an internal implementation status accurately, but should avoid certification-like claims unless authorized. Phrases such as 'aligned with' or 'implementing' should be supported and scoped.

Use is subject to applicable trademark and certification-mark rules. Referencing the framework for factual identification is different from implying certification, sponsorship or endorsement.

No. GAISSF and ISO schemes are separate. Mappings may show relationships, but one certificate should not be represented as a substitute for another unless a formal recognition mechanism exists.

No. It may provide evidence relevant to obligations, but legal compliance depends on jurisdiction, facts, system use and regulator interpretation.

Yes, under an applicable certification scheme, for material nonconformity, scope misrepresentation, failed surveillance, misuse of marks, non-payment, refusal of assessment or other defined causes.

They should identify the organization or system, scope, GAISSF version, profile, certificate status where applicable, issuing body and relevant limitations.

Claims implying universal safety, zero risk, regulator endorsement, ISO equivalence, whole-enterprise certification from a narrow scope, or guaranteed legal compliance should not be made.

ISO/IEC 42001 provides an AI management-system standard. GAISSF can complement it with detailed security, safety, technical and evidence-oriented controls. Neither should be presented as automatically equivalent to the other.

NIST AI RMF provides a risk-management structure and outcomes. GAISSF can translate those outcomes into a detailed control, evidence and assurance model.

NIST CSF provides broad cybersecurity outcomes. GAISSF extends the operating model into AI-specific model, data, agentic, harmful-output and physical-AI risks.

OWASP resources provide important application, LLM and agentic threat knowledge and test guidance. GAISSF adds governance, lifecycle, evidence, assurance, supplier and certification structures.

MITRE resources help identify adversary tactics and techniques. GAISSF uses threat knowledge to support control design and testing but adds normative control and evidence expectations.

CIS Controls provide a prioritized cybersecurity baseline. They can support many shared security mechanisms but do not cover the full AI-specific GAISSF scope.

Yes. GAISSF-IMP-012 provides a structured migration method based on inventory, normalization, semantic mapping, evidence reuse, gap assessment, transition waves and legacy-control retirement.

No. A crosswalk shows a relationship between requirements. Conformance still requires implementation and evidence in the assessed scope.

The organization should operate control-health monitoring, model and data monitoring, incident response, supplier oversight, evidence refresh, exception review, management review and recurring assurance.

Control health is the current operating state of a control, commonly expressed as green, amber, red or unknown based on defined signals and thresholds.

Drift should be monitored against approved baselines. Threshold breaches should trigger investigation, re-evaluation, restriction, rollback or risk acceptance as appropriate.

Loss of monitoring should be treated as a control issue. For high-risk systems, the organization may need to restrict capability, pause expansion, fail closed or revert to an observable state.

Exceptions should identify the control, scope, reason, risk, compensating measures, owner, approver, expiry, monitoring and remediation plan.

It is the systematic use of incidents, test failures, metrics, audit findings, user feedback, supplier issues and threat intelligence to improve control design and operation.

The frequency should reflect risk and profile. Quarterly and annual reviews are common, with event-driven review after material incidents, changes or framework releases.

Retirement should remove access and integrations, manage data, terminate suppliers, archive required evidence, update inventories and claims, and assign residual obligations.

Internal use depends on the applicable GAISSF licence and published terms. Organizations should review the current licence rather than assume unrestricted reuse.

Commercial use, advisory use, certification services, training, embedding and redistribution may be subject to separate permissions or licences. The current licence terms should be consulted.

Copyright, licence and trademark rules apply. Factual references and controlled mappings differ from reproducing, adapting or commercializing the framework.

Embedding control content, schemas, validation logic, APIs or branded claims may require authorization under the applicable licensing model.

They may reference it subject to copyright, citation and trademark rules. Adoption, incorporation or derivative use should be governed through formal permission and attribution arrangements.

No. Citation of GAISSF by another organization, or citation of an external standard by GAISSF, does not by itself imply endorsement, affiliation or formal recognition.

Yes. Buyers may use GAISSF controls and profiles to define supplier requirements, due diligence, evidence expectations, contract clauses and ongoing monitoring.

Not necessarily. Requirements should be proportionate to dependency and risk. Some suppliers may provide evidence, contractual commitments or independent assurance without full certification.

Customers should ask for exact scope, version, profile, applicable controls, certificate status, evidence period, known limitations, supplier dependencies and incident-notification commitments.

Suppliers should avoid vague claims such as 'GAISSF certified' without identifying scope, version, profile, issuing body and status.

Identify the provider, control outcome, evidence, contractual basis, limitations, monitoring, fallback and the responsibility retained by the customer.

They may reduce effort, but should not automatically replace system-specific evidence, especially where integration, data use, configuration or customer operation changes the risk.

No. The controls require governance, architecture, operation, evidence, testing, assurance and improvement. A completed checklist without evidence is not conformance.

No. Maturity and conformance are different. Advanced monitoring cannot compensate for an unmet mandatory control unless an approved exception process permits a temporary deviation.

Not necessarily. It is an adoption profile, not a declaration that the system is low risk. High-risk systems may require all controls and additional sector obligations.

No. Red teaming samples known scenarios and methods. It cannot prove the absence of unknown or low-frequency attacks.

Not automatically. Transparency should be meaningful and proportionate while respecting security, privacy, intellectual property and legal constraints.

No. Oversight can fail because of poor interface design, automation bias, insufficient authority, time pressure, lack of competence or unavailable evidence.

Activities may be outsourced, but accountability for the organization’s system, users, obligations and risk generally remains with the organization.

Not necessarily. Incidents may be rare, under-detected or under-reported. Effectiveness should be evaluated using multiple evidence sources.

Monitoring is required according to applicable controls and risk. The Optimized profile adds more advanced and integrated continuous-monitoring expectations.

No. It provides a structured way to reduce, detect, govern and evidence risk. Residual uncertainty and risk remain.

Start with GAISSF-NOR-004, then consult GAISSF-IMP-010, IMP-011, IMP-013 and IMP-014. Document architecture decisions and unresolved assumptions.

Use GAISSF-NOR-001, the controlled profile register and the Statement of Applicability. Escalate material ambiguity through framework governance.

Use the applicable certification scheme, trademark policy, certificate scope and claims rules. Do not rely on general FAQ wording for an individual certificate decision.

Record the affected document, clause or control, the suspected defect, evidence, impact and proposed correction. Submit it through the controlled change or issue process.

Questions should be evaluated for recurrence, materiality and whether they reveal a normative ambiguity. Informative clarification may be added to the FAQ; requirement changes must follow formal change governance.

Return to the normative requirements, document the interpretation used, identify assumptions, obtain appropriate legal or specialist advice where needed, and preserve the decision for review.