Functional support
- Administrator assistance
- Recertification campaigns
- Business user guidance
OPERATE, STABILIZE, IMPROVE
IAM operations: keeping identity services reliable and evolving
An IAM platform does not stop at go-live. Identity sources evolve, applications change, connectors fail and business requirements continue to move.
Ariovis supports the functional and technical operation, incident resolution, maintenance, monitoring and continuous improvement of IAM, IGA, Access Management, CIAM and PAM environments. In French, this scope is often referred to as “RUN IAM”.
What Ariovis IAM operations cover
IAM operations are more than a ticketing channel. They combine business expertise, platform knowledge, technical monitoring and continuous improvement.
Technical support
- Error analysis
- Non-production reproduction
- Targeted corrections
Incidents & anomalies
- Qualification
- Workaround
- Service restoration
- Permanent resolution
Connectors & flows
- SCIM, LDAP, JDBC, API
- Reconciliation
- Post-incident recovery
Corrective maintenance
- Vendor patches
- Configuration fixes
- Regression handling
Evolutive maintenance
- Small developments
- New connectors
- Workflow adjustments
Versions
- Vendor watch
- Recommendations
- Testing and deployment
Recertifications
- Campaign support
- Corrections
- Compliance reports
Data quality
- Discrepancy detection
- Cleanup
- Automated controls
N2/N3 expertise
- Advanced analysis
- Build team contribution
- Vendor escalation
Reporting
- Service KPIs
- Recurring committees
- Incident reports
Continuous improvement
- Prioritized backlog
- Automations
- Runbooks
Fast response is not enough
Response, service restoration and root cause resolution
An IAM support offering that only acknowledges tickets resolves nothing. The client expects Ariovis to intervene, restore an acceptable state, and then durably eliminate the underlying cause.
We explicitly distinguish three commitments: acknowledgement / response time, service restoration time, and eradication (root cause resolution). Each answers a different question and is contracted separately.
Example service-level framework
The matrix below illustrates values previously proposed by Ariovis for critical and major incidents. It is a starting point for contractual negotiation.
Ariovis does not only commit to acknowledging a ticket. Depending on the contract, Ariovis can also commit to service restoration targets and a defined path to permanent resolution.
These figures illustrate a service-level framework previously proposed by Ariovis. Final commitments depend on scope, service hours, criticality, available access, shared responsibilities and vendor dependencies.
| Priority | GTI | GTR | Eradication | Post-mortem |
|---|---|---|---|---|
P1 Critical incident | 2 hours | 8 hours | 10 business days | 3 business days after restoration |
P2 Major incident | 4 hours | 24 hours | 20 business days | On request |
- Response time (GTI)
- Maximum time for an Ariovis engineer to effectively intervene on the incident — beyond the automatic ticket acknowledgement.
- Service restoration time (GTR)
- Maximum time to restore an acceptable state, through a permanent fix, a controlled workaround or a vendor escalation that enables restoration.
- Eradication
- Contractual timeframe to deliver the fix that permanently removes the incident’s cause. Distinct from service restoration.
- Post-mortem
- Structured post-incident analysis, delivered within 3 business days after restoration of a P1 incident.
Typical post-mortem content
- Origin of the incident
- Detailed timeline
- Operational and functional impact
- Workaround applied
- Validated corrective action
- Non-recurrence measures
- Optional problem record
- SLA compliance follow-up
An SLA only makes sense when its starting point and dependencies are clear
A service commitment cannot be read in isolation. It relies on an environment, service hours, access, and shared responsibilities. Here are the conditions to clarify before any figure is committed.
- Applicable service hours
- Exact moment the clock starts
- Correct priority classification
- Availability of remote access
- Environment coverage in the supported scope
- Availability of logs and diagnostic evidence
- Client responsibilities
- Ariovis responsibilities
- Vendor responsibilities
- Infrastructure dependencies
- Difference between service restoration and permanent resolution
- SLA suspension rules when the required action depends on a third party
More than an email address: the Ariovis service platform
Ariovis operates its own support platform, with a single entry point and differentiated processes according to request type. It is the operational foundation of the service.
Portal capabilities
- Online portal available 24/7 to raise a request
- Real-time ticket status
- Interaction and action history
- Full timestamping
- Criticality qualification
- Assignment to the right team
- Configurable notifications
- Attachments and evidence
- Traceable escalations
- Formal closure with client agreement
- Optional dedicated mail-to-ticket address
- Single entry point, differentiated processes
Distinct request categories
- Incidents
- Anomalies
- Changes
- Change requests
- Catalog requests
- Information requests
- Functional assistance
- Project / advisory requests (per contract)
Not all requests follow the same SLA. Incident SLAs do not apply to service requests.
From ticket to lasting knowledge
- Portal / email / phone
- Qualification
- Criticality
- L1
- L2
- L3 / build team
- Vendor if required
- Service restoration
- Permanent resolution
- Closure and knowledge capture
Service hours and coverage: three notions not to confuse
Portal available 24/7
The Ariovis support platform lets you raise and follow requests at any time. This continuous availability is independent from staffed intervention hours.
Standard staffed coverage
Ariovis has already proposed a 9 a.m.–6 p.m. staffed support model with a dedicated team. This is one available coverage model, not the only formula.
Extended or continuous coverage
Extended hours, on-call, smarthands or 24/7 monitoring can be part of a specific contractual scope. They are agreed case by case.
Portal availability should not be confused with staffed support hours. Support windows, on-call coverage and SLA calculation rules are defined contractually.
L1, L2, L3, build and vendor — one chain, one point of contact
The client keeps a single point of contact. Behind that entry point, Ariovis mobilises multiple layers of expertise depending on complexity.
L1 — Qualification & quick resolution
- Intake
- Scope verification
- Impact and urgency
- Information gathering
- Runbook lookup
- Known-issue resolution
- Initial communication
L2 — Functional and technical IAM expertise
- Data and workflow analysis
- Job analysis
- Connector investigation
- Configuration review
- Non-production reproduction
- Fix or workaround proposal
- Client validation
L3 — Product experts & build team
- Complex defects
- Architecture
- Advanced code or configuration
- Regressions
- Fix development
- Pre-production validation
- Production rollout support
Vendor
- Vendor ticket opening and tracking
- Evidence submission
- Escalation management
- Follow-up until fix
- Consolidated client communication
Ariovis remains the client’s single point of contact — even when a vendor escalation is required. You don’t coordinate three suppliers in parallel: we do.
Ariovis does not solely commit to the fix timeline for a product defect that depends entirely on the vendor. Ariovis owns the escalation, the service restoration and the communication.
Monitoring connected to support
Good IAM monitoring does not just display green lights. It detects signals, qualifies them and triggers actions.
- Job monitoring
- Import / export tracking
- Synchronisation controls
- Provisioning / de-provisioning controls
- Connector errors
- Queue depth
- Abnormally long executions
- Repeated failures
- Unusual volumes
- Orphan accounts
- Gaps between expected and actual state
- Campaign errors
- Component availability
- Certificate / secret expiry (when in scope)
Depending on scope, monitoring alerts can automatically create records in the Ariovis support platform, allowing an anomaly to be assessed before it is reported by an end user. A Zabbix-style integration is possible; it is not activated by default across all environments.
Service and change requests: indicative timelines
Non-incident requests follow a distinct cycle. The indicative timelines below illustrate values already used in contracts, and are clearly distinct from incident SLAs.
Catalog request
- Qualification & validation
- 2 business days
- Kick-off
- Within 5 business days
Out-of-catalog request
- Qualification & validation
- 5 business days
- Kick-off (< 20 days effort)
- Within 5 business days after qualification
- Kick-off (> 20 days effort)
- Within 10 business days after qualification
These timelines cover the qualification and kick-off of service and change requests. They must not be confused with the response and restoration SLAs applicable to incidents.
enOperational service governance
IAM operations need clear roles. Depending on the contract, Ariovis mobilises a set of functions dedicated to service management and delivery.
Steering
- Service manager
- Support manager
- Client focal point
Expertise
- Technical experts
- Functional experts
- Build team on demand
- Vendor interface
Processes
- Incident management
- Problem management
- Change management
- Backlog management
Decision
- KPIs
- Risks
- Capacity
- Budget
- Recommendations
Indicative service committee: quarterly frequency, 1 hour, with the Ariovis support manager, the client’s manager or project lead and relevant stakeholders. Agenda: incidents, SLA compliance, recurring causes, corrective actions, changes, versions, recommendations, improvements, risks, capacity, consumption.
The quarterly frequency is an example, not a requirement. Cadence is tuned to service criticality and contractual scope.
Possible service KPIs
Incidents
- Number of incidents
- P1 and P2 counts
- Average response time
- Average restoration time
- SLA compliance
- Reopenings
- Recurring incidents
- Backlog and backlog age
IAM platform
- Import success
- Sync success
- Provisioning / de-provisioning success
- Errors per connector
- Reconciliation gaps
- Data quality
- Orphan accounts
- Blocked jobs
Requests & changes
- Requests received
- Qualification lead time
- Delivery lead time
- Successful changes
- Cancelled changes
- Rollbacks
- Production success rate
Value
- Manual operations avoided
- Friction removed
- New use cases
- Scope embedded
- Automations delivered
- Recommendations implemented
These KPIs are examples. The effective set depends on service maturity, platform and client priorities. Historical performance values are not fabricated.
IAM operations is not waiting for the next ticket
A good service analyses what happens, captures lessons and reduces the incident surface. Ariovis embeds a structured proactive stream in the service.
- Recurring incident analysis
- Root cause investigation
- Runbook improvement
- Data quality analysis
- Review of fragile connectors
- Job optimisation
- Removal of manual operations
- Version preparation
- Vulnerability review
- Architecture recommendations
- Backlog review
- New use case identification
- Control automation
- Documentation improvement
- Administrator coaching
An incident resolved without lessons captured is an incident likely to return.
Closing the ticket is not always the end of the work. For major incidents, it must be followed by root cause analysis, an eradication action and a non-recurrence check.
Version and patch management
- Vendor version watch
- Release notes review
- Version recommendation
- Non-production deployment
- Testing
- Non-regression
- Go-live decision
- Deployment support
- Post-deployment follow-up
- Patch handling
- Vendor interface
- Accelerated handling for critical vulnerabilities
An annual version upgrade cycle can be included in some contracts. It is not automatically included in every offering.
From build to operations, without disruption
Operations are prepared during the build. The Ariovis support manager is engaged before go-live, not after. This timeline shows the typical build-to-run transition.
- 1. Design
- 2. Testing
- 3. Documentation
- 4. Go-live
- 5. Hypercare
- 6. Handover
- 7. Operations
- 8. Continuous improvement
Anonymized references
A selection of representative IAM operations engagements. Scopes are described in strict respect of contractual confidentiality.
Public sector
Sensitive IGA platform takeover
Sensitive migration of an IGA platform, skills transfer and long-term managed operations.
Software & HR services
Stabilising a service under pressure
Takeover of a platform with too many incidents, no roadmap and limited internal autonomy. Stabilisation, pipeline restructuring and continuous improvement.
International retail
Multi-entity IAM programme
Realignment of a multi-entity IAM programme, improved velocity, clearer priorities and stabilised operations.
International organisation
Rationalisation around Entra ID
IAM landscape rationalised around Entra ID, progressive decommissioning of components and simplified operations.
Transport / construction
PAM programme takeover
Takeover of PAM programmes, clarified usage, application onboarding and re-mobilisation of the setup.
Anonymized references. No client is named without written authorization.
IAM operations delivered by complementary teams
Our operations and consulting teams are spread across four locations. A single contract can mobilise several sites depending on skills, escalation level and service organisation.
Paris
Steering, service governance and client relationship.
Châtillon — Hauts-de-Seine
Consulting, technical expertise, integration and complex escalations.
Bordeaux — Nouvelle-Aquitaine
Technical and consulting expertise, evolutions and platform support.
Brussels
Team particularly focused on managed operations and managed services for Benelux, Switzerland and Germany.
Locations are not silos. The same client can be served by Paris for governance, Bordeaux for expertise and Brussels for managed operations.
Going further
IAM operations extend our integrator craft and prepare — where relevant — the transition to a fully managed identity service (IAM managed services). For a broader picture, explore our integrator approach, our managed services offering and our locations map.
Frequently asked questions about IAM operations
What are IAM operations?
IAM operations cover all the activities that keep an identity and access management platform running: functional and technical support, incidents, corrective and evolutive maintenance, flow monitoring, version management and continuous improvement.
How do IAM operations differ from application maintenance (TMA) or maintenance in operational conditions (MCO)?
TMA (third-party application maintenance) is a contractual model mostly focused on corrections and evolutions, often driven by work units. MCO (maintenance in operational conditions) covers the continuous availability of a system. Ariovis IAM operations is a broader service combining support, MCO, corrective and evolutive maintenance, monitoring and continuous improvement, with dedicated governance.
What does N2/N3 IAM support cover?
L2 brings functional and technical IAM expertise: workflows, connectors, configurations. L3 brings product and build-team expertise: advanced fixes, regressions, pre-production and production rollout. Ariovis can cover both levels and drives the vendor escalation when needed.
What is the difference between response time and service restoration time?
Response time is the maximum delay for an actual intervention on the incident. Service restoration time is the maximum delay to restore an acceptable state — through a fix, a workaround or a vendor escalation that enables restoration.
Does Ariovis only commit to acknowledgement?
No. Depending on the contract, Ariovis can also commit to service restoration and to a defined path to permanent resolution. This is what distinguishes real IAM operations from a basic first-level support desk.
How is service restoration time calculated?
The clock starts when the incident is properly declared through the contractual channel with the correct priority. It is paused when the expected action depends on a third party (client, hosting provider, vendor) and resumes when that action is provided.
What does incident eradication mean?
Eradication is the durable removal of the incident’s root cause, after service restoration. It may require a vendor patch, a configuration change, an evolution or a procedure change.
What is an IAM post-mortem?
It is a structured analysis delivered after a major (P1) incident. It documents the origin, timeline, impact, workaround, corrective action and non-recurrence measures. Ariovis delivers it within a maximum of 3 business days after restoration.
Is the ticketing platform available 24/7?
Yes. The Ariovis portal lets you raise and follow requests at any time. Portal availability is independent from staffed intervention hours, which are defined contractually.
Is staffed support available 24/7?
Not by default. Ariovis has proposed a 9 a.m.–6 p.m. staffed support model with a dedicated team. Extended hours, on-call and 24/7 monitoring are part of a specific contractual scope.
How is an incident escalated to the vendor?
Ariovis opens and follows the vendor ticket, submits evidence, drives escalation until a fix is delivered and consolidates communication to the client. The client keeps a single point of contact.
Can Ariovis take over operations for a platform integrated by someone else?
Yes. We regularly take over IAM platforms built by other integrators. The takeover starts with a state audit, an access inventory, a review of existing documentation, then a hypercare phase before full handover.
Can Ariovis operate several IAM technologies?
Yes. Our approach is vendor-agnostic. We operate Netwrix Identity Manager, Ping Identity, Entra ID, Keycloak, Axiomatics, Netwrix Privilege Secure, Keeper and existing CyberArk environments, among others.
How are IAM connectors monitored?
By combining execution metrics (success, failures, duration, volume), threshold alerts and automated ticket creation in the support portal. Depending on scope, alerts can create a qualified ticket directly.
How to prepare the transition from build to operations?
By involving the support manager before go-live, documenting extensively, organising a hypercare period, formalising the handover, and starting continuous improvement from day one of operations.
What does an IAM operations report contain?
It presents incidents for the period, SLA compliance, recurring causes, corrective actions, changes, versions, recommendations, improvements, risks and capacity consumption.
How are recurring incidents handled?
By opening a problem record, investigating the root cause, building an eradication action and validating non-recurrence. This is part of the proactive operations stream.
Is a version upgrade included in operations?
It can be included in some contracts as an annual cycle. It is not automatically included in every offering and is explicitly contracted.
Does Ariovis operate in Paris, Bordeaux and the Hauts-de-Seine area?
Yes. Ariovis has teams in Paris, Châtillon (Hauts-de-Seine) and Bordeaux (Nouvelle-Aquitaine). These teams contribute to consulting, integration, L2/L3 support and platform improvement.
Which team runs managed operations from Brussels?
The Ariovis Brussels team is particularly focused on managed operations and managed services. It covers Benelux, Switzerland and Germany, in close coordination with the French teams.
IAM operations to take over, stabilise or frame?
Let’s talk. A first, no-commitment discussion helps qualify your context, the current maturity of the service, and the priorities of the next milestone.