In force
Interoperable Europe Act: Regulation in application
Shared governance for interoperable public services across EU borders and for reuse of public solutions.
Government & Public Sector
Accountable by design, for every resident.
We design, build and run digital services for government: accessible under GIGW 3.0, secure from the first release, built on national digital infrastructure and documented well enough to outlive the contract. Our methods come from 600+ government projects for public bodies across the European Union.
For Central Government ministries and departments, State governments, urban local bodies and PSUs that must serve every resident, accountably and accessibly.
March 2023
GIGW 3.0 issued
Government websites and apps are to meet WCAG 2.1 at level AA.
November 2025
DPDP Rules notified
Rules on the Data Protection Board apply at once; the remaining duties follow in two later steps.
May 2027
Data Fiduciary duties apply
Notice, security safeguards, breach intimation, retention and contact information under the DPDP Rules.
600+Projects for European public administrations
- Public bodies in EU Member States
Credentials
- ISO/IEC 27001 certifiedInformation security management, independently certified
- Summit Partner · SalesforceOn platforms many departments and PSUs already use
- Gold Partner · SAP and OdooOn platforms many departments and PSUs already use
Public bodies we work with
- Infrabel BE
- Skeyes BE
- Bundesimmobiliengesellschaft (BIG) AT
- Austro Control AT
- Bulgarian Ports Infrastructure Company BG
- HŽ Infrastruktura HR
- Cyprus Ports Authority CY
- Správa železnic CZ
- DPP Prague CZ
- Naviair DK
- Energinet DK
- Elering EE
- Fintraffic FI
- Fingrid FI
- RATP Group FR
- EYDAP GR
- HungaroControl HU
- EirGrid IE
- ANAS IT
- Augstsprieguma tīkls (AST) LV
- Lithuanian Airports LT
- Litgrid LT
- LuxAirport LU
- Indis Malta MT
- TenneT NL
- PANSA PL
- Infraestruturas de Portugal PT
- Transelectrica RO
- NDS SK
- Enaire ES
What is shifting for Indian government
Data protection reaches every department
The DPDP Rules phase in over eighteen months: Board rules from November 2025, Consent Manager registration from November 2026, and Data Fiduciary duties such as notice, safeguards and breach intimation from May 2027. Any system holding residents’ personal data needs a stated purpose, a consent record where consent is the basis, and an access log.
SourceG.S.R. 846(E)
Residents expect to share a document once
DigiLocker lets residents store, share and verify issued documents and certificates, and API Setu makes government APIs available to other departments. People now expect a department to fetch what another has already issued instead of asking for a fresh upload.
SourceDigiLocker
Experience leaves on transfer and retirement
Officers move on transfer and senior staff retire, taking with them the reasons a rule is applied as it is. That reasoning has to be captured in documented services and searchable records that a newly posted officer can use on the first day.
AI has to be explainable to the resident
MeitY’s India AI Governance Guidelines are guidelines, not a statute, yet a department using AI must still explain an outcome to the resident and name the officer accountable for it. That shapes the design of an AI service, not only its procurement.
Problems we are asked to solve
- The problem
Scheme and case systems are old, and every amendment to a scheme means a risky release.
What we would doWe modernise in stages behind stable APIs: extract services, migrate records with reconciliation and switch off modules one at a time, so residents never face an overnight cutover.
- The problem
Residents submit the same certificates to one department after another.
What we would doWe design services to fetch issued documents through DigiLocker and department APIs offered on API Setu, with a stated purpose for each fetch and an entry in the access log.
- The problem
Helplines and front offices absorb questions the portal should answer.
What we would doA service assistant that answers from your notified rules, government orders and published FAQs, can be configured for the languages your residents use, and passes the resident to an officer when judgement is required.
- The problem
Section staff spend hours reading, sorting and re-keying applications.
What we would doDocument intelligence classifies each application and extracts its fields; an officer confirms the uncertain values, and the case system receives structured data with an audit trail.
- The problem
AI pilots stall because nobody can say who is accountable for an output.
What we would doWe plan for review from the first workshop: a risk assessment with reference to the India AI Governance Guidelines, a named approving officer, a log of every output and documentation an internal audit team can follow.
- The problem
Government orders, circulars and office memoranda are spread across portals and files.
What we would doKnowledge search that respects access rights and cites the order, circular or notification behind each answer, so that an officer can verify before acting.
EU milestones behind our public-sector practice
The European dates our teams build against for public bodies in the EU. They do not bind Indian departments; they explain the habits we bring to your programme.
In force
NIS2: Member State NIS2 laws take effect
Public administrations come within scope as each national law is adopted, with risk and incident duties.
In force
Interoperable Europe Act: Interoperability assessment becomes mandatory
Needed before new or substantially changed trans-European digital public services.
In force
AI Act: Banned practices take effect
Social scoring by public authorities among them; AI literacy duties begin on the same day.
In force
European Accessibility Act: Accessibility rules for products and services
Applied through Member State laws to services such as banking and e-commerce.
In force
Data Act: Data Act takes effect
Exceptional-need data requests by public bodies, and rules for switching cloud provider.
In force
AI Act: Transparency duties take effect
People must be told when they deal with an AI system, and generated content must be marked.
Position on 2 October 2026
Ahead
eIDAS 2: Digital Identity Wallets offered
Every Member State offers at least one wallet, which public services requiring online identification must accept.
Ahead
AI Act: High-risk duties take effect
Covers stand-alone high-risk uses such as access to public benefits, under the 2026 amendment.
EU instruments, read from India
The European rules our teams work under for public bodies in the EU. They do not bind Indian departments; each entry closes with the Indian rule or system that covers similar ground, and what we would do about it.
An orientation for planning, not legal advice. EU transpositions vary by Member State, and the Indian rules are summarised as they stood on 6 November 2026. EU dates reviewed on 2 October 2026.
- EU AI ActScopeEU instrument
Sorts AI systems by risk. In the EU, AI that decides on access to public services and benefits, migration, justice or law enforcement is high-risk, and public deployers carry out a fundamental rights impact assessment (Article 27), assign human oversight and retain logs, from 2 December 2027 under the 2026 amendment.
An Indian provider falls within it when its AI system is placed on the EU market or its output is used in the Union (Article 2(1)(a) and (c)).
In India, and what we would doIndia has no AI statute; MeitY’s India AI Governance Guidelines of November 2025 are non-binding. We apply the same discipline either way: risk classification at discovery, a named officer over every consequential output, logs and documentation. Legal interpretation remains with your own legal advisers.
SourceRegulation (EU) 2024/1689, EUR-Lex (opens external site)
- NIS2ScopeEU instrument
Brings central government administrations of EU Member States within cybersecurity law through national statutes, with risk management, supply-chain security and incident reporting that begins with an early warning within 24 hours.
In India, and what we would doThe Indian counterpart is CERT-In: its Directions of 28 April 2022 require listed cyber incidents to be reported within six hours and ICT logs to be retained. We design incident handling and logging around that shorter clock.
SourceDirective (EU) 2022/2555, EUR-Lex (opens external site)
- eIDAS 2 and the EU Digital Identity WalletScopeEU instrument
Each EU Member State must offer at least one EU Digital Identity Wallet by 24 December 2026, and public services that require electronic identification must accept it next to the national schemes.
In India, and what we would doIn India, identity runs on Aadhaar-based authentication and issued documents on DigiLocker. We design identity so that a new credential or document type is a matter of configuration, never a rebuild.
SourceRegulation (EU) 2024/1183, EUR-Lex (opens external site)
- Interoperable Europe ActScopeEU instrument
In application since 12 July 2024. Since 12 January 2025, EU public bodies assess interoperability before deciding on new or substantially changed trans-European digital public services, and are encouraged to reuse shared and open-source solutions.
In India, and what we would doThe Indian parallel is reuse of national building blocks run by the National e-Governance Division (NeGD), such as DigiLocker and API Setu. We start from what already exists and document every interface so that other departments can adopt it.
SourceRegulation (EU) 2024/903, EUR-Lex (opens external site)
- Single Digital Gateway and once-onlyScopeEU instrument
Since 12 December 2023, users of key cross-border procedures in the EU can ask for evidence to pass directly between authorities through the Once-Only Technical System, instead of uploading it.
In India, and what we would doDigiLocker serves a comparable purpose at home: the resident shares a document from the issuing department rather than a scan. Each fetch should carry consent, a preview and a log entry, and that is how we would build it.
SourceRegulation (EU) 2018/1724, EUR-Lex (opens external site)
- Web Accessibility Directive and EN 301 549ScopeEU instrument
EU public-sector websites and apps meet EN 301 549, which builds on WCAG, and publish an accessibility statement with a route for feedback.
In India, and what we would doIndian government sites follow GIGW 3.0, which requires WCAG 2.1 level AA, and the Bureau of Indian Standards’ IS 17802 is aligned with WCAG 2.1 and EN 301 549. We design and test to WCAG 2.2 AA, which serves both.
SourceDirective (EU) 2016/2102, EUR-Lex (opens external site)
- European Accessibility ActScopeEU instrument
In application since 28 June 2025, through national laws, to consumer products and services on the EU market such as banking, e-commerce, e-books and passenger transport. It binds economic operators rather than public bodies, although EU procurement uses its requirements.
In India, and what we would doIt reaches Indian companies that provide such services to consumers in the EU. For Indian government work, GIGW 3.0 and IS 17802 are the references, and we treat accessibility as an acceptance criterion from the first sprint.
SourceDirective (EU) 2019/882, EUR-Lex (opens external site)
- Data ActScopeEU instrument
In application since 12 September 2025. EU public bodies may request company data in cases of exceptional need, and providers of data processing services must make switching possible, with switching charges phased out by January 2027.
In India, and what we would doExit matters just as much in an Indian department’s cloud contract. We write an exit plan and data portability into the architecture, so that a change of provider is planned work rather than an emergency.
SourceRegulation (EU) 2023/2854, EUR-Lex (opens external site)
Public procurement, and how we prepare for it.
Central ministries, departments and autonomous bodies buy goods and services available on the Government e-Marketplace (GeM) through GeM, under rule 149 of the General Financial Rules, 2017, and receive bids through e-procurement portals such as the Central Public Procurement Portal (CPPP) under rule 160.
Whether and how FromNine can take part in a particular procurement in India is something we confirm case by case. What we bring is the discipline of European public tenders: an answer to every clause of the bid document, named team members, transparent pricing and a delivery plan an evaluation committee can score.
Pre-bid stage
We explain what is technically realistic without shaping the specification in anyone’s favour. Early clarity reduces the risk of an RFP nobody can deliver.
Bid document and queries
We read the RFP against the law, the standards and your current systems, and raise queries only through the official channel.
Technical bid
A structured response: architecture, plan, team, security and accessibility approach, with an exit plan from the outset.
Award and onboarding
Named people, onboarding to your security policies and an agreed scope for the first release.
Delivery and handover
Reporting against the contract indicators, documented handover and return of data, so the next procurement starts on clean ground.
Data location and security
- Data location in the contract
Where data is stored, who holds the encryption keys and from where support is given are decided with you before build and written into the contract and the architecture.
- Transfers under the DPDP Act
Personal data may be transferred outside India unless the Central Government restricts a country by notification (section 16(1)); a stricter sectoral rule prevails (section 16(2)). We design for whichever applies to you.
- Reuse before build
We look first at national building blocks and open-source components, and build only what is missing.
- Certified security management
FromNine is ISO/IEC 27001 certified: controls, supplier management and incident handling run under a certified information security management system.
- Six-hour incident readiness
Incident channels, log retention and clock synchronisation are agreed per contract, so that your organisation can report to CERT-In within six hours.
Building on national digital infrastructure
Illustrative example
Identity, the portal and the case system sit on an API layer that reads from the departments that issued the data.
Read the diagram as text
A resident or an enterprise signs in to a department portal, with Aadhaar-based authentication where the service requires it. A service assistant answers questions and opens the right application form.
The portal hands the request to the case system, where an officer reviews exceptions and takes the decision.
Portal and case system read what they need through an API layer made up of API Setu and department APIs. That layer fetches certificates issued by departments, enterprise registrations and scheme and payment records, and writes every access to a log.
Documents a department has already issued reach the service through DigiLocker, which obtains them from the issuing department with the resident’s consent.
Fetch, never copy
Services retrieve issued documents and records from the department that owns them instead of keeping copies of their own.
Documented APIs
Interfaces are documented and versioned so that other departments can consume them, for example through API Setu.
Purpose and log
Each exchange records its purpose, the consent where consent is the basis, and an access entry an auditor can trace.
Aadhaar only where needed
Aadhaar-based authentication is designed in where a service requires it, requesting nothing beyond what that service needs.
Accessibility under GIGW 3.0
WCAG 2.2 AA as our baseline
GIGW 3.0 requires WCAG 2.1 level AA for government websites and apps. We design and test to WCAG 2.2 AA, the later version.
Tested by tools and by people
Automated checks in the pipeline, manual audits with screen readers and keyboard only, and sessions with users with disabilities wherever your department can arrange them.
Indian languages as a system feature
Where a service must publish in Indian languages, the system supports it and your language team reviews the content; our own teams work in English.
Statements kept current
The accessibility statement and its feedback route are updated with every release that changes the service.
Identity and consent
Aadhaar-based authentication
Designed in only where a service needs it, through the route your department is authorised to use.
Documents through DigiLocker
Issued certificates fetched through DigiLocker with the resident’s consent, so fewer scans need checking by hand.
Minimum data, recorded consent
Ask only for the data a service needs, show the resident what is shared and keep a record of it.
Acting for others
Applications made on behalf of a family member or an enterprise, which many schemes and licences require.
Parts of government we design for
Central ministries and departments
Shared platforms, registers and back-office systems used across a ministry, its attached offices and autonomous bodies.
State governments
Scheme delivery, licences and certificates, where every decision on an entitlement must be explainable.
Urban local bodies
Property tax, building permissions, grievances and resident services for municipal corporations and municipalities.
Public sector undertakings
Finance, HR, procurement and customer systems for PSUs, often on SAP and always open to audit.
Education and research institutions
Student administration, scholarships and research data services.
Illustrative use cases
Illustrative exampleScheme application intake
Applications and supporting certificates are classified and checked for completeness; an officer reviews every flagged item before any sanction.
Resident information assistant
Answers procedural questions for a municipal corporation in the languages configured for the service, shows the page it relied on and passes the resident to staff when judgement is needed.
Search across government orders
Officers search government orders, circulars and office memoranda in one place, within their access rights, with a link to the source behind each answer.
Licensing system rebuilt in stages
A State department’s licensing system is replaced section by section behind a stable API, with records reconciled at each step and the old system switched off last.
Public grievance handling
Grievances are logged, matched to the responsible office and given a drafted reply with the relevant records attached. An officer approves every reply.
Two workflows, start to finish
How the components work together day to day. Both are illustrative designs, not descriptions of client work.
Resident service: from first question to closed request
Illustrative workflow- Step 01Authenticate
The resident signs in, with Aadhaar-based authentication where the service requires it. Only the details the service needs are requested.
- Step 02Ask or apply
An assistant answers from approved content, or opens the correct application form.
- Step 03Fetch documents
Certificates already issued are fetched through DigiLocker with the resident’s consent and shown for confirmation.
- Step 04Route
The request reaches the responsible section with its full history, so the resident is never asked twice.
- Step 05Officer decides
Human checkpoint. An officer handles exceptions and anything requiring judgement. The assistant never decides an entitlement.
- Step 06Inform
Status and decision reach the resident through the portal, by SMS or by email, with the route to appeal stated plainly.
Application processing: from receipt to a recorded decision
Illustrative workflow- Step 01Receive
Applications come through the portal, by email or at the counter, where paper is scanned into the same queue.
- Step 02Classify
Each document is classified and its fields extracted, with a confidence score per field.
- Step 03Check
Rules identify missing items and prepare a deficiency letter for the officer to send.
- Step 04Officer review
Human checkpoint. The officer confirms uncertain fields and takes the decision. System suggestions are marked as suggestions.
- Step 05Record
Decision, reasons and the data relied on are written to the file and to the audit log.
- Step 06Improve
Corrections made by officers join the test set, so accuracy is measured with every release.
Platforms in government and PSUs
Salesforce
Summit PartnerGrievance desks, beneficiary contact and field inspections, connected to department registers and to Aadhaar-based authentication where the department uses it.
SAP
Gold PartnerFinance, HR and procurement for PSUs and departments, with SAP linked to case systems and data platforms so that the core stays stable.
Odoo
Gold PartnerA practical back office for smaller autonomous bodies and urban local bodies, with open-source licensing to evaluate.
Partner tiers shown are FromNine’s own. Product names belong to their respective owners.
India
India’s digital public infrastructure, and what Europe taught us
Indian public services increasingly sit on shared national building blocks: Aadhaar-based authentication from the Unique Identification Authority of India (UIDAI), DigiLocker and API Setu run by the National e-Governance Division (NeGD), and, for buying, GeM and the CPPP under the General Financial Rules, 2017. Government websites and apps follow GIGW 3.0.
In European public administrations we learned to reuse before building, to log every data exchange and to treat accessibility as an acceptance criterion. We would bring the same habits to these Indian building blocks, as designs for your programme.
- GIGW 3.0Guidelines for Indian Government Websites and Apps (GIGW 3.0, March 2023), requiring WCAG 2.1 level AA (opens external site)
- IS 17802IS 17802, Bureau of Indian Standards accessibility standard for ICT products and services (opens external site)
- DPDP Act 2023Digital Personal Data Protection Act, 2023, also covering processing outside India connected with offering goods or services to Data Principals in India (opens external site)
- General Financial Rules 2017General Financial Rules 2017 (Department of Expenditure), including the GeM and e-procurement rules (opens external site)
- Interoperable Europe ActInteroperable Europe Act, Regulation (EU) 2024/903 (opens external site)
- AadhaarAadhaar digital identity, issued by the Unique Identification Authority of India (UIDAI), a statutory authority under the Aadhaar Act, 2016 (opens external site)
- National e-Governance Division (NeGD)National e-Governance Division (NeGD), a division of Digital India Corporation under MeitY that runs DigiLocker, UMANG and API Setu (opens external site)
- Government e-Marketplace (GeM)Government e-Marketplace (GeM), mandatory for central government purchases of goods and services available on it (opens external site)
- Central Public Procurement Portal (CPPP)Central Public Procurement Portal (CPPP), developed by NIC (opens external site)
Frequently asked questions
What public-sector experience do you have?
600+ government projects for public bodies across the European Union, completed and ongoing. We name public bodies only with their permission, and share references within a procurement under the conditions the contracting authority sets. What carries over to an Indian department is the method: recorded decisions, audit trails and accessibility as an acceptance criterion.
Can our department procure your services through GeM or the CPPP?
Tell us the procurement route and the category. We will confirm whether and how FromNine can take part before you invest time in it; we make no assumption about eligibility.
How do you govern AI in a public service?
We classify the use case at discovery, with reference to the India AI Governance Guidelines and, where the output is used in the EU, the EU AI Act. Where an outcome affects a resident’s entitlement, a named officer decides, every output is logged and the documentation is ready for audit.
Where will our data be stored?
Where you decide, and as your sectoral rules require. Storage location, encryption key control and support locations are agreed before build and recorded in the contract and the architecture documents.
Will the service meet GIGW 3.0?
We design and test to WCAG 2.2 level AA, which goes beyond the WCAG 2.1 level AA that GIGW 3.0 requires, combine automated and manual testing, and keep the accessibility statement in step with each release.
Can a service publish in Indian languages?
Yes, as a feature of the system: interfaces, content and assistants can be configured for the languages your residents use, with the content reviewed by your own language team. We hold the first conversation in English and agree the working language of the project at the start.
Plan your next public service with us
Preparing an RFP, modernising a scheme system or bringing AI into a resident service? Talk to a team used to procurement discipline, accessibility rules and audit trails.