Looking for Guidance on Structuring Data Sensitivity Attributes in EA

[kcf]

Hi everyone — we’re looking for some guidance on how best to model a growing set of data‑sensitivity classifications within the Enterprise Architecture (EA) application.

Our risk partners require application owners to certify whether their applications contain various categories of sensitive data (all simple Yes/No indicators). The list continues to expand, and we expect more categories to be added over time.

Why we currently store these on the Business Application record:
We need these fields to be included in the out‑of‑the‑box Data Certification process, and we also sync the values through a 1:1 mapping to Information Objects. For now, adding custom fields on the Business Application table has allowed us to keep everything aligned with this certification workflow — but we’re concerned this won’t scale well as the number of attributes grows.

Before we commit to a heavier customization, we’re hoping to get input from the community and any EA product experts on the following:

1. Is it advisable to continue adding these Yes/No classification fields directly on the Business Application table?
2. Is EA the appropriate module for housing a large and expanding set of sensitivity classifications, or is there a better‑suited module or pattern?
3. Are there recommended approaches for managing structured questionnaires or attribute sets that need to be included in recurring certifications?
4. Any best practices for aligning these types of fields with the standard data‑certification process and with Information Object mappings?

The types of categories we’re capturing today include things like:

• Client or employee‑related personal information
• Compliance‑driven or regulatory classifications
• Internal corporate or proprietary data
• Certain IT or security data types

(We only capture Yes/No flags — no raw data.)

If anyone has implemented something similar or can share guidance on scalable patterns or product‑recommended approaches, we’d really appreciate the insight.

Thanks in advance!

[Mathew Hillyard]

Hi @kcf 

This is the purpose of Data Domains and Information Objects. It is expected that these are related to Business Applications.

Basically an Information Object describes the nature of data as per your categorisations above, and Data Domains are groupings of related Information Objects.

Data Domain example

PII (Personally Identifiable Information)

Information Object examples

• Bank account number
• Customer full name
• Customer home address
• Date of birth
• Passport number
• Salary
• Telephone number
• Vehicle registration plate

There are more examples of Data Domains with their Information Objects if you install EA with demo data in a PDI (e.g. Employee, PCI, PHI and Sensitive PII).

I hope this helps!

Mat

[Rahul Adokar]

Adding question attributes in cmdb_ci_business_app table is not so scalable; model a custom application if you must for your data sensitivity management requirements. I have used Assessments for questions like these to satisfy immediate need; however, for the long term 

I would replace the OOB Data Certification with a dynamically generated certification based on the custom app table. Strategy is simple, use as much OOB as possible. Create an Information Object IO for each sensitivity classification. Associate Applications → Information Objects using OOB EA relationships. Use IO categories or groupings to organize classifications.  Best part is that you are on a right path already! All the best.