Applications Inventory and Attributes - Security and Compliance attributes for the Applications Inventory
Applications Inventory and Attributes
Security and Compliance attributes for the Applications Inventory
Security and Compliance attributes capture the regulatory obligations and security posture of each application — essential for audit readiness, regulatory compliance management, and data residency governance.
| Attribute Name | Maturity | Description and Notes |
|---|---|---|
| Data Classification | Crawl | Description — The classification of the data this application handles, based on the organization's data classification policy: Public, Internal, Confidential, or Restricted. Benefit(s) — Determines the minimum security controls, access restrictions, audit requirements, and regulatory governance obligations that apply to the application. An organization that has not classified the data handled by every application cannot ensure its security controls are calibrated to its actual data sensitivity profile. Source — Manually Entered — assessed by the Data Owner in accordance with the organization's data classification policy. Examples — Restricted (payment processing system — payment card data), Confidential (HR portal — employee records and compensation data), Internal (project management tool — internal project data), Public (corporate website CMS) Notes — Valid values: Public, Internal, Confidential, Restricted. Use the most sensitive classification that applies when the application handles data of multiple classifications. |
| PII / PHI Indicator | Crawl | Description — An indicator of whether the application processes, stores, or transmits Personally Identifiable Information (PII) or Protected Health Information (PHI) as defined by applicable privacy and healthcare regulations. Benefit(s) — The single most important compliance trigger in the portfolio. Applications that handle PII or PHI are subject to regulatory requirements — GDPR, HIPAA, CCPA, and similar frameworks — that determine data handling standards, breach notification obligations, and potential liability. Source — Manually Entered. Notes — Valid values: PII, PHI, Both, Neither. |
Sensitive Data Type(s) Handled [Multi-Value] | Walk | Description — The specific categories of sensitive data the application processes, stores, or transmits — for example, financial account data, payment card data, health records, biometric data, government identification numbers, or location data. Benefit(s) — Provides the granular data type context needed to determine which specific regulatory frameworks, security controls, and privacy obligations apply to the application beyond the top-level classification that Data Classification provides. Source — Manually Entered. |
Regulatory Frameworks Applicable [Multi-Value] | Walk | Description — The specific regulatory frameworks, compliance standards, and legal obligations that apply to this application based on the data it handles, the jurisdictions in which it operates, and the industries it serves. Benefit(s) — Identifies the precise compliance obligations the application must satisfy, enabling audit readiness tracking, compliance gap analysis, and investment prioritization for compliance remediation. Without explicit regulatory framework attribution, compliance programs cannot ensure complete portfolio coverage. Source — Manually Entered. Examples — SOX, PCI-DSS (payment processing application), HIPAA, GDPR (patient portal handling EU patient data), SOC 2 (cloud-hosted SaaS platform) Notes — Common values: SOX, HIPAA, GDPR, PCI-DSS, CCPA, SOC 2, ISO 27001, DORA, FedRAMP. Include all frameworks that apply. |
| Compliance Status | Walk | Description — The current status of the application's compliance with its applicable regulatory frameworks: Compliant, Conditionally Compliant (compliant with exceptions or compensating controls), Non-Compliant, or Under Assessment. Benefit(s) — Enables portfolio-level compliance reporting to leadership and regulators, identification of non-compliant applications requiring priority remediation investment, and proactive preparation for regulatory examinations and audits. Source — Manually Entered — assessed by the Security Owner and Compliance function. Notes — Valid values: Compliant, Conditionally Compliant, Non-Compliant, Under Assessment, Not Applicable. |
Data Residency / Sovereignty Requirements [Multi-Value] | Walk | Description — The geographic or jurisdictional requirements governing where data processed by this application must be stored and processed. Benefit(s) — Essential for applications operating across jurisdictions with data sovereignty laws that create legal liability when data residency requirements are violated. Without explicit tracking, cloud hosting decisions and disaster recovery configurations may inadvertently violate applicable legal requirements. Source — Manually Entered. Notes — Express as jurisdiction or region: for example, European Union, United States, Germany, AWS eu-west-1. |
| Access Control Model | Walk | Description — The access control approach governing user authentication and authorization for this application: Single Sign-On (SSO), Multi-Factor Authentication (MFA), Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), or legacy username/password. Benefit(s) — Identifies applications with inadequate access controls relative to their data sensitivity and regulatory requirements. Applications handling Confidential or Restricted data without MFA and RBAC represent a security posture gap that is only visible when access control model is tracked systematically. Source — Manually Entered. Notes — Common values: SSO + MFA + RBAC, SSO + RBAC, MFA only, Username/Password only. Multiple values may apply. |
| Identity Provider / IAM System | Walk | Description — The identity management system or identity provider used to authenticate and authorize users of this application. Benefit(s) — Enables enterprise identity governance, simplifies security audit scope definition, and identifies applications not integrated with the enterprise identity platform — creating shadow identity stores that are difficult to govern and audit. Source — Manually Entered. Notes — Examples: Microsoft Entra ID (Azure AD), Okta, Ping Identity, AWS IAM, Application-Specific (legacy). |
| Last Security Audit Date | Walk | Description — The date on which the most recent security audit, assessment, or penetration test was conducted for this application. Benefit(s) — Enables portfolio-level tracking of security audit coverage and cadence, identifying applications overdue for security review relative to their data sensitivity and regulatory requirements. Source — Manually Entered. |
| Security Audit Result | Walk | Description — The outcome of the most recent security audit: Passed, Passed with Findings, Failed, or Remediation In Progress. Benefit(s) — Provides the governance record of each application's security audit history and enables tracking of remediation progress against audit findings. Source — Manually Entered. Notes — Valid values: Passed, Passed with Findings, Failed, Remediation In Progress, Not Yet Audited. |
| Open Security Findings Count | Run | Description — The number of unresolved security findings — vulnerabilities, control gaps, or audit exceptions — currently open against this application across all security assessment sources. Benefit(s) — Enables portfolio-level tracking of unresolved security debt and provides a quantitative basis for prioritizing security remediation investment. A large number of open security findings indicates either a security culture problem, an inadequate remediation process, or insufficient security engineering capacity. Source — Derived from the Risks and Issues Inventory: count of open security finding records associated with this application's Semantic Identifier. |
Copyright for the International Foundation for Information Technology (IF4IT): 2008 - Present
Legal Disclaimers