KPMG in India: ISO/IEC 42001 Certification for a RAG Based AI Platform
How we took an AI platform from existing practice to an ISO/IEC 42001 certificate with the least possible new paperwork.
KPMG in India asked us to help certify one of its AI platforms against ISO/IEC 42001, the international standard for AI management systems. The platform lets users bring their own data and query it through retrieval augmented generation (RAG). SGS certified the AI management system in December 2025 for the Gurugram and Noida offices. This case study explains how we got there.
At a glance
| Client | KPMG in India |
| AI system | AI platform where users bring their own data, built on retrieval augmented generation |
| Standard | ISO/IEC 42001:2023, AI management system |
| Certification body | SGS |
| Certified | December 2025, Gurugram and Noida offices |
| Our role | AIMS implementation, from gap assessment to certification audit support |
| Duration | About seven weeks from the start of work |
| Approach | Build on existing practice, integrate with the ISMS, keep documentation to the minimum |
The starting point
KPMG in India did not start from zero. It already ran a mature information security management system (ISMS) under ISO/IEC 27001. Security reviews and privacy impact assessments were in place for its systems. Its teams had working practices for building and releasing software.
What was missing was a frame that tied these practices to the specific asks of ISO/IEC 42001 for an AI system. The risk in a project like this is duplication. A new policy set, a new risk register and a new stack of procedures would have doubled the work for teams that were already audited every year. We set out to avoid that.
Our approach: structure, do not rebuild
We mapped each existing practice to the clauses and Annex A controls of ISO/IEC 42001 before we wrote anything new. Where a practice already met the intent of a requirement, we kept it and recorded the link. We wrote new material only where the standard asked for something that did not exist.
- Integrated with the ISMS. ISO/IEC 42001 and ISO/IEC 27001 share the same management system structure, and Annex D of ISO/IEC 42001 expects them to work together. We extended the existing ISMS processes for context, leadership, internal audit, management review and corrective action to cover the AI management system. There was no second system running beside the first.
- Absolute minimum documentation. We kept to the documented information the standard requires: the AIMS scope, the AI policy, AI objectives, the results of the risk and impact assessments, and the Statement of Applicability. Everything else lived in the procedures and records the teams already used.
- Reuse of existing assessments. The security reviews and privacy impact assessments already in place became inputs to the AI risk assessment and the AI system impact assessment. Teams answered each question once.
- Intent over volume. Every artefact had to show an auditor how the organisation met the intent of a clause. Page count was never the measure.
What we added
Three pieces were new, because the existing practices did not cover them for an AI system.
- AI system impact assessment. We designed and ran the AI system impact assessment that ISO/IEC 42001 requires in clause 6.1.4 and Annex A.5. It looked at the consequences of the platform for individuals, groups and society. It drew on the existing privacy impact assessment for the questions about personal data.
- AI risk assessment. We set up the AI risk assessment and treatment under clauses 6.1.2 and 6.1.3. It covered AI specific risk sources such as data quality, transparency, misuse of outputs and AI security threats. The treatment decisions flowed straight into the Statement of Applicability.
- LLMOps in the SDLC procedure. The existing software development life cycle (SDLC) procedure was written for regular software. It had no steps for building an AI platform or for deploying RAG. The platform uses large language models with retrieval and does not train its own models, so MLOps was out of scope. We added LLMOps steps to the SDLC procedure instead. The next section lists them.
The LLMOps steps we added to the SDLC
LLMOps is the discipline for running applications built on large language models. It covers prompts, retrieved context, evaluation, release, guardrails and monitoring. A RAG platform also has a data life cycle for its sources, so the steps cover both. We wrote each step into the SDLC procedure the developers already followed, and linked it to the Annex A control it meets.
| SDLC stage | LLMOps step we added | ISO/IEC 42001 control |
|---|---|---|
| Requirements | Record the intended use, what a good answer looks like, what the system must refuse and who owns the risk. | A.6.2.2 |
| Design | Document the RAG design: data sources, chunking and embedding settings, the vector store, the model and the guardrails. | A.6.2.3 |
| Data sources | Approve each source before ingestion. Check its quality and record its origin. Carry the user’s access rights into the vector store, so each user retrieves only the data they brought. | A.7.2 to A.7.6 |
| Model selection | Record the model, version and provider. Check the provider terms on the use and retention of prompts and data. | A.10.3 |
| Build | Put prompts, system instructions and retrieval settings under version control and change control, in the same way as code. | A.6.2.3 |
| Testing | Test against a set of real tasks for grounded answers, relevance and refusal. Add security tests for prompt injection and data leakage between users. | A.6.2.4 |
| Release | Approve each release against the test results before deployment. | A.6.2.5 |
| Operation | Log prompts, retrieved context and responses within the retention rules. Monitor answer quality, user feedback, cost and response time. | A.6.2.6, A.6.2.8 |
| Change | Repeat the tests when the model, a prompt or a data source changes. Remove a user’s data from the index when their use ends. | A.6.2.6 |
None of this needed a new procedure. The developers kept one SDLC, with AI steps where AI made a difference.
Working with the CIO and the National IT Security Officer
The CIO sponsored the programme and stayed close to it. That made decisions quick. Scope, risk acceptance and the AI policy were settled by people with the authority to settle them.
The National IT Security Officer (NITSO) and the NITSO team owned the security controls and the ISMS, and worked with us on the integration throughout. Because the same people ran the ISMS and the new AIMS processes, there was one set of owners, one audit trail and one management review.
The result
The implementation took about seven weeks from the start of work. That is fast for a first AI management system. SGS certified it in December 2025 for the Gurugram and Noida offices. KPMG in India now runs AI governance as part of its existing management system, with a small set of new documents and no parallel bureaucracy.
What other organisations can take from this
- Start from what you have. An ISMS, security reviews and privacy impact assessments already cover a large part of ISO/IEC 42001.
- Add only what AI needs. The AI system impact assessment, the AI risk assessment and AI life cycle controls are the usual gaps.
- Match the life cycle to the system. A RAG platform on a bought model needs LLMOps steps in the SDLC, not a full MLOps stack.
- Put senior owners in the room. A sponsoring CIO and an engaged NITSO team decide in days what committees take months to decide. That is a large part of how we finished in seven weeks.
Planning ISO/IEC 42001 for your own AI systems?
We help organisations in India and abroad implement ISO/IEC 42001 on top of the systems they already run. Request a call back or write to Sandhya Khamesra. You can also read about our ISO/IEC 42001 consulting, see what certification costs and how long it takes, or run the free CERT-In self assessment.
Talk to an ISO/IEC 42001 consultant
Leave your details and we will call you back to discuss your scope. No obligation.