Services Inventory and Attributes - Security attributes for the Services Inventory
Services Inventory and Attributes
Chapter 18. Security attributes for the Services Inventory
Executive Summary: Chapter Overview
IF4ITThe Bottom Line
Core Concepts
| Concept | Definition & Strategic Role |
|---|---|
| Service Sensitivity Classification | Public, Internal, Confidential, or Restricted — the foundational classification that drives security control selection proportional to Service sensitivity. |
| Authentication and Authorization | How identities prove who they are (SSO, OAuth, mTLS, API Key) and what authenticated identities can do (RBAC, ABAC, ACL) — supports identity governance and standardization. |
| Data Classification Handled | The data sensitivity classes the Service touches — PII, PHI, PCI, Confidential Financial — enabling compliance teams to traverse from regulated data to affected Services. |
| Encryption Posture | Encryption in Transit and Encryption at Rest — separate attributes because they answer different security questions and warrant different remediation when missing. |
Quick Q&A
Question: How does Service Sensitivity Classification interact with Data Classification Handled?
Question: Why are Encryption in Transit and Encryption at Rest separate attributes?
Read More Below
Security attributes capture each Service’s security posture — sensitivity classification, authentication and authorization, data classification handled, security review status, encryption posture, and identity provider. These attributes support security governance and compliance discipline.
| Attribute Name | Maturity | Description and Notes |
|---|---|---|
| Service Sensitivity Classification | Crawl | Description — The sensitivity classification of the Service — what level of confidentiality, integrity, and availability protection the Service warrants. Benefit(s) — Drives security control selection proportional to Service sensitivity. Enables compliance reporting by sensitivity tier. Supports incident triage and response prioritization. Source — Manual. Examples — Public, Internal, Confidential, Restricted Notes — Valid values: Public (no sensitivity concerns), Internal (information for internal use only), Confidential (sensitive enterprise information), Restricted (highly sensitive, requiring strict access control). |
Authentication Method [Multi-Value] | Walk | Description — The authentication methods accepted or required to engage the Service. Benefit(s) — Supports identity and access management governance. Enables analysis of authentication standardization across the Service portfolio. Source — Manual. Examples — SSO (Okta); OAuth 2.0; Mutual TLS; API Key; Username/Password Notes — A Service may accept multiple authentication methods (e.g., interactive users via SSO, programmatic access via API key). Record all accepted methods. |
| Authorization Model | Walk | Description — The authorization model the Service uses to determine what authenticated identities can do. Benefit(s) — Supports access governance design. Enables analysis of authorization standardization across the Service portfolio. Source — Manual. Examples — RBAC (role-based); ABAC (attribute-based); ACL (access control list); Custom Notes — Valid values include RBAC, ABAC, ACL, Custom, or descriptive text for hybrid models. |
Data Classification Handled [Multi-Value] | Walk | Description — The data sensitivity classifications the Service handles — drawn from the enterprise data classification taxonomy. References the Data Sensitivity Types Inventory by Semantic ID where governed there. Benefit(s) — Enables compliance and security analysis: which Services handle PII, PHI, PCI, or other regulated data classifications? Supports regulatory mapping and impact analysis. Source — Manual. Examples — PII, PHI, PCI, Confidential Financial, Public Notes — A Service may handle data of multiple classifications. Record all that apply. Refer to the planned Data Sensitivity Types Inventory for the canonical classification taxonomy. |
| Security Review Status | Walk | Description — The current security review status of the Service — whether security review is approved, pending, or expired. Benefit(s) — Supports security governance: which Services have current security approval and which require re-review? Enables risk-informed Service deployment and operation decisions. Source — Manual. Examples — Approved, Pending, Expired, Not Required, In Review Notes — Some low-sensitivity Services may legitimately be classified Not Required. Should be paired with Last Security Review Date for governance visibility. |
| Last Security Review Date | Walk | Description — The date of the most recent formal security review of the Service. Benefit(s) — Enables expired-review detection. Supports security governance cadence aligned to Service sensitivity. Source — Manual. Examples — 2026-02-15 Notes — For Services where Security Review Status is Not Required, this attribute may be empty. |
| Encryption in Transit | Walk | Description — Whether data in transit through the Service is encrypted. Benefit(s) — Supports security and compliance reporting. Enables identification of Services requiring encryption uplift. Source — Manual. Examples — Yes (TLS 1.3); Yes (TLS 1.2); No; Not Applicable Notes — For Services that do not transmit data, Not Applicable may be valid. For Services that transmit sensitive data, encryption should be in place. |
| Encryption at Rest | Walk | Description — Whether data at rest associated with the Service is encrypted. Benefit(s) — Supports security and compliance reporting. Enables identification of Services requiring encryption uplift. Source — Manual. Examples — Yes (AES-256); Yes (provider-managed keys); Yes (customer-managed keys); No; Not Applicable Notes — For Services that do not store data, Not Applicable may be valid. |
| Identity Provider | Walk | Description — The identity provider the Service uses for authentication of its Service Requesters. Benefit(s) — Supports identity governance: which Services depend on which identity providers, and where identity provider consolidation is possible. Source — Manual. Examples — Okta; Azure AD; Google Workspace; Service-specific identity store Notes — For Services with multiple identity providers (e.g., one for employees, one for external customers), record all in Notes. |
How to cite this page
When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.
Example (informal web citation):
The International Foundation for Information Technology (IF4IT), LLC. Security attributes for the Services Inventory | Services Inventory and Attributes. https://if4it.org/best-practices/services-inventory-and-attributes/security-attributes-for-the-services-inventory/ (accessed 2026-07-23).
See About Us for content governance and site-wide citation guidance.
Copyright for The International Foundation for Information Technology (IF4IT), LLC: 2008 - Present
Legal Disclaimers