Initial tenant support framework defining IronSled support hours, request and incident response targets, tenant responsibilities, platform ownership boundaries, maintenance communications, and escalation paths.

IronSled Service Delivery and Shared Responsibilities

Initial Tenant Support Framework | Version 1.0

This document establishes practical communication, support, and ownership expectations between IronSled and tenant application teams. The targets create predictability and transparency; they do not replace judgment, collaboration, or mission impact with rigid metrics.

Guiding principles

IronSled prioritizes mission impact, service restoration, security, and clear communication over mechanically meeting a metric.
Response targets are operating objectives, not guarantees or contractual remedies. They may be adjusted based on severity, complexity, staffing, dependencies, and competing mission priorities.
Resolution time cannot always be predicted. IronSled provides status, ownership, next steps, and known constraints while work is underway.
Support targets apply only when a request includes enough information to begin work. Time waiting on tenant input, approvals, external providers, or government dependencies is not counted against the target.
This framework is reviewed and refined as IronSled matures and learns from tenant needs.

Supported hours and after-hours support

Standard support window

IronSled provides routine support Monday through Friday during normal business hours, excluding federal holidays and approved closures. Requests submitted outside the support window are reviewed during the next business day.

After-hours support

Support outside normal business hours is not automatically available. Tenants requiring planned evening, overnight, weekend, or holiday support must coordinate with the IronSled Project Manager at least one week, or five business days, before the need. IronSled confirms whether coverage can be provided based on staffing, mission priority, and the nature of the activity. Submitting a request does not guarantee coverage.

Unplanned emergencies

For an unexpected critical event outside supported hours, tenants should use the published escalation channel. Response is best effort unless after-hours coverage was previously confirmed.

How to request support

Submit requests through the designated IronSled support channel or ticketing process. Include:

Affected environment and application
User impact and urgency
Time the issue was first observed
Recent changes
Relevant logs or screenshots
A tenant point of contact

Use the escalation path only when the impact or urgency materially exceeds the normal request process.

Incident priorities and communication targets

Priority is determined by actual impact, scope, available workaround, security implications, and mission urgency—not solely by the priority selected by the requester.

Priority	Typical impact	Initial response target	Update target	Primary goal
P1 — Critical	Platform-wide outage, confirmed severe security event, or production service unavailable for multiple tenants with no reasonable workaround.	Within 1 business hour during supported hours.	At least every 2 business hours, or when meaningful information changes.	Restore service, contain risk, and coordinate affected parties.
P2 — High	Major degradation, production impact to one tenant, or significant function unavailable with limited workaround.	Within 4 business hours.	At least once each business day while actively unresolved.	Reduce impact and establish a recovery plan or workaround.
P3 — Standard	Limited impact, non-production issue, access request, routine defect, or question with a workaround.	Within 1 business day.	As milestones, blockers, or expected completion change.	Clarify ownership, next action, and reasonable delivery expectation.
P4 — Planned / Request	Enhancement, onboarding activity, configuration change, consultation, or future need.	Within 2 business days.	During planning or when schedule or priority changes.	Assess, prioritize, and schedule through normal planning processes.

Initial response means acknowledgment by a person who has reviewed the request, confirmed the priority or requested additional information, and identified the next action. It does not mean the issue will be resolved within that period.

Request and change expectations

Request type	IronSled operating target	Tenant responsibility
Onboarding / environment requests	Acknowledge within 1 business day and identify missing inputs, owner, and next step. Scheduling depends on readiness, complexity, security approvals, and team capacity.	Provide complete and accurate technical, security, funding, access, and scheduling information; maintain an available technical point of contact.
Deployment assistance	Begin coordination after required artifacts, approvals, scans, and environment prerequisites are complete. A specific deployment date is confirmed through scheduling, not assumed from submission.	Provide functional and tested deployment artifacts, clean or adjudicated security results, release notes, validation steps, and rollback procedures.
Feature requests / custom capabilities	Acknowledge within 2 business days and evaluate through prioritization and roadmap planning. Acceptance does not imply immediate delivery.	Describe the tenant outcome, urgency, users affected, alternatives considered, and requested timeline.
Access requests	Acknowledge within 1 business day after receipt of complete authorization information.	Provide approved roster, role, environment, sponsor or approver, and any required training or documentation.

Shared responsibility summary

IronSled secures and operates the shared platform. Tenant teams build, secure, test, operate, and maintain their applications. Detailed responsibilities are confirmed during onboarding and may vary by service offering.

Area	IronSled team	Tenant application team
Platform infrastructure	Provision, maintain, patch, monitor, and secure shared platform infrastructure and IronSled-managed services.	Design the application to operate within platform constraints and promptly report platform-impacting issues.
Application code and images	Provide supported platform patterns, base capabilities, and available scanning tools.	Own application source code, dependencies, containers, configuration, Helm/deployment artifacts, testing, and release quality.
Security and vulnerabilities	Operate platform security controls, identify platform findings, and communicate tenant-relevant findings and required timelines.	Use secure coding practices; review and remediate application, dependency, image, and configuration findings within required security timelines.
Identity and access	Manage platform-level access, permissions, and IronSled-managed identity integrations.	Manage application-level roles and permissions, validate users, and promptly submit roster and access changes.
Monitoring and incidents	Monitor and respond to platform-level health, availability, and security events; communicate known tenant impact.	Monitor application behavior and performance, maintain useful logs, troubleshoot application issues, and immediately report suspected incidents or breaches.
Data and privacy	Protect IronSled-managed infrastructure and services according to the platform authorization and approved architecture.	Classify and protect application data; obtain application-specific privacy, security, and mission approvals; implement application-layer controls as required.

Boundaries and exclusions

Application defects, application performance tuning, business logic, data quality, and failures caused by tenant code or configuration remain the tenant team’s responsibility.
Custom pipelines, dedicated runners, nonstandard integrations, or capabilities outside the published IronSled service offering are feature requests unless explicitly agreed otherwise.
IronSled is not responsible for delays caused by incomplete tenant inputs, unavailable tenant personnel, external service providers, government approvals, network owners, security review organizations, or other dependencies outside IronSled control.
Targets may be temporarily adjusted during major incidents, surge periods, staffing constraints, planned maintenance, or competing mission-critical work. IronSled communicates material changes when practical.

Maintenance and service communications

IronSled communicates planned maintenance and expected tenant impact as early as practical. The operating target is at least five business days of notice when the work is known and schedulable.
Emergency maintenance may occur with less notice when necessary to protect security, stability, or mission operations.
For significant incidents, communications identify known impact, current owner, actions underway, available workarounds, and the next expected update. Root-cause analysis is provided when appropriate and useful.

Escalation and review

Operational escalation: Route operational issues through the designated IronSled support channel or ticketing process. When impact or urgency materially exceeds the normal request process, use the published escalation path to reach the on-call platform lead.

Program or priority escalation: For program-level or priority concerns, escalate to the IronSled Project Manager through the same IronSled support channel.

Service Delivery

On this page