Business context

Business context enriches your software catalog with the organizational, financial, and operational signals that help prioritize work, assess risk, and align engineering decisions with business objectives. It complements technical metadata by answering: "What matters most to the business?"

When AI agents and workflows understand this context, they can prioritize vulnerabilities by revenue impact, route incidents to the right owner, and enforce policies automatically — all without human triage.

What business context includes

Cost and financial context

• Cost center attribution - track which department or budget owns each resource via AWS Cost integration or Kubecost.
• Revenue impact - tag services that directly generate revenue or support revenue-generating features.
• Cloud spending patterns - understand resource costs to inform optimization and prioritization decisions.

Criticality and risk context

• Business criticality levels - classify services (e.g. mission-critical, customer-facing, internal tooling) to drive different SLA requirements, triage workflows, and automation policies.
• Disaster recovery tier - define RTO/RPO requirements based on business impact to inform backup strategies and incident response priorities.
• Data sensitivity - mark resources handling PII, financial data, or regulated information to enforce compliance controls.
• Compliance scope - tag services subject to SOC 2, GDPR, HIPAA, or PCI-DSS to ensure audit readiness.

Operational context

• SLAs and SLOs - define service-level agreements and objectives to measure reliability, track MTTR, and ensure SLA compliance.
• On-call ownership - integrate PagerDuty schedules to understand who is responsible right now for incident response.
• Escalation policies - define who to notify and when for different severity levels based on business impact.

Organizational context

• Team affiliation - connect services to teams via GitHub CODEOWNERS or Jira project mappings for clear ownership.
• Reporting hierarchy - map organizational structure (team → department → division) for escalation paths.
• Business unit alignment - associate services with product lines or business units to understand impact radius.

Customer and product context

• Customer tier - identify which customer segments are affected (e.g. enterprise, gold-tier, freemium) to prioritize incidents and features affecting high-value customers.
• Product lifecycle stage - tag services by maturity (closed beta, open beta, GA, deprecated) to set appropriate expectations and SLAs.

Why business context matters

When AI agents and workflows have access to business context, they can:

• Prioritize vulnerabilities affecting revenue-generating production services over internal dev tools.
• Route incidents to the right on-call engineer based on service ownership and escalation policies.
• Estimate blast radius of a deployment by understanding dependent services and their business criticality.
• Automatically enforce policies like "critical services must have SLOs defined" or "PII-handling services require SOC 2 compliance checks".
• Calculate risk scores that combine technical severity (CVSS) with business impact (criticality, revenue, SLA, customer tier).
• Adjust incident response based on affected customer tier - a P1 incident affecting enterprise customers triggers immediate executive notification, while the same issue in closed beta may follow standard on-call procedures.

Examples

Risk-based vulnerability triage

Scenario: A critical CVE is discovered in a library used by multiple services.

Without business context: The security team gets hundreds of alerts with no clear way to prioritize which services to patch first.

With business context in Port:

1. Port enriches each vulnerability with:

   • Service business criticality (mission-critical vs. internal).
   • Revenue impact (directly revenue-generating or not).
   • SLA requirements (99.99% uptime vs. best-effort).
   • Data sensitivity (handles customer PII or not).
   • Compliance scope (subject to SOC 2 audit).
   • Customer tier (enterprise vs. freemium).

2. An AI agent or automation calculates a risk score:

   Risk = CVE Severity × (Business Criticality + Revenue Impact + SLA Weight + Compliance Factor + Customer Tier)

3. Results in a prioritized triage queue:

   • Fix immediately: Payment service (mission-critical, revenue-generating, 99.99% SLA, PCI-DSS scope, enterprise customers).
   • Fix this sprint: Customer portal (customer-facing, revenue-supporting, 99.5% SLA, gold-tier customers).
   • Backlog: Internal dev tools (low criticality, no SLA, internal users only).

Learn more: Prioritize vulnerabilities with business context.

Context-aware incident routing

Scenario: A production API starts returning 500 errors during business hours.

Without business context: A generic "production down" alert leads to manual escalation and wasted time finding the right owner.

With business context in Port:

1. Port's incident automation queries the context lake for:

   • Service on-call schedule from PagerDuty.
   • Service business criticality and SLA (99.99% uptime).
   • Revenue impact (payment processing = revenue-blocking).
   • Customer tier affected (enterprise customers experiencing errors).
   • Product lifecycle stage (GA with 10,000+ active users).
   • Recent deployments (was there a recent change?).

2. Automation takes action based on context:

   • Closed beta, freemium users: page on-call engineer via standard PagerDuty workflow.
   • GA, enterprise customers: immediate P1 escalation → page incident captain, notify VP Engineering, create executive war room.

3. Result: faster MTTR and an appropriate response because both responders and escalation paths match business impact.

Learn more: Generate incident updates with n8n and Port.

Disaster recovery policy enforcement

Scenario: A platform team needs to ensure all mission-critical services have disaster recovery plans.

Without business context: Manual spreadsheet tracking leads to inconsistent enforcement and audit findings.

With business context in Port:

1. Services are tagged with:

   • Business criticality (mission-critical, high, medium, low).
   • Disaster recovery tier (Tier 1: RTO < 1hr, Tier 2: RTO < 4hr, Tier 3: RTO < 24hr).
   • Customer tier impact (affects enterprise vs. freemium).
   • Product lifecycle (GA services have stricter DR requirements than beta).

2. A Port automation enforcement policy:

   IF service.businessCriticality == "mission-critical"
   AND service.productLifecycle == "GA"
   AND service.disasterRecoveryTier != "Tier 1"
   THEN fail_scorecard("Missing DR Plan")
   AND create_jira_ticket(owner, "Define DR plan with RTO < 1hr for GA mission-critical service")

3. A scorecard dashboard shows:

   • 12/15 mission-critical GA services have Tier 1 DR plans.
   • 3 services out of compliance → auto-created tickets assigned to owners.
   • Beta services excluded from strict DR requirements until GA launch.

Learn more: Compliance as code.

How to ingest business context

Business context comes from many sources:

• Cloud providers - cost data via AWS Cost and Kubecost.
• Incident management - on-call schedules via PagerDuty and ServiceNow.
• Source control - team ownership via GitHub CODEOWNERS and GitLab.
• Project management - business unit and stakeholders via Jira.
• Manual enrichment - business criticality, revenue impact, SLAs, customer tier, and product lifecycle added as blueprint properties and updated via self-service actions or API.

How to model business context in Port

Some of the most valuable catalog context is knowledge that already exists in your organization but is scattered across teams and tools. The following patterns show how to capture that context in Port so humans, workflows, and agents can use it consistently.

Set up ownership

Ownership answers "who is responsible for this service right now." It enables routing, escalation, approvals, and accountability across the SDLC.

If you use Port's default components, start with the default ownership model and extend it to match your org.

To go deeper, see Ownership in Port and Default blueprints.

Set up service criticality and tiers

Criticality and tiering help you prioritize engineering work and apply different policies by service importance - for example, incident response expectations, approval requirements, or compliance checks.

Model criticality as a property on the entities you care about (for example, services) and use scorecards and workflows to enforce stricter standards for high-criticality services.

Set up team assignments

Team assignments capture how services, repositories, and infrastructure map to teams. This supports routing, dashboards, and agent workflows that need to know which team owns an asset.

To go deeper, see Manage users and teams and Ownership in Port.

Set up tags and labels

Tags and labels let you slice your catalog consistently - for example, by domain, environment, customer impact, or compliance scope.

Use blueprint properties to model the tags you care about, then use search and query to filter entities by those tags.

Add custom metadata

Custom metadata is where you capture organization-specific signals that are not available from integrations - for example, support tier, internal readiness gates, or ownership exceptions.

To go deeper, see Set up blueprints.