Working with a Taxonomy XML File
A taxonomy can be exported as an XML file, and then edited. When you export a taxonomy, you can choose whether to include the rules and extractors. Extractors appear as a group at the top of the file. For information on the extractor XML blocks, see Working With Extractors. The first time a rule is referenced in a taxonomy, the rule XML appears inline within the category block. If the rule is used again on a subsequent category, only a reference to the rule is included. For information on rule XML, see Elements of Rule XML.
You can edit the XML directly to modify the taxonomy, and then import it into your environment. For more information, see Importing and Exporting Taxonomies. The taxonomy itself is comprised of the following blocks:
| Tag | Description |
| <Name> | The name of the taxonomy. This is followed by the settings on the top node of the taxonomy. For details, see Creating Taxonomies. |
| <Category> | Each category has a name and description, as well as tags for all category settings. For details on the implications of changing these settings, see Editing a Category. |
| <Rule> | The rule XML is contained within the category block. There may be more than one rule associated with a category. Note that modifying the rule may affect other categories associated with that rule. For more details, see Modifying Rule XML. |
Managing the Life Cycle of Taxonomies and Categories
Over time, you may deploy and change multiple taxonomies. Changes to taxonomies once they are in production requires careful management in order to ensure the most accurate system with the least amount of disruption.
Taxonomy Deployment Considerations
Using Quest One Identity Manager to deploy a taxonomy is very simple—create a taxonomy with at least one published category, and your system can yield results. However, practically speaking, there are many things to consider before you deploy a taxonomy in your production environment. Once you publish your first category, business owners may begin manually categorizing resources. Data Governance administrators, classification analysts, compliance officers and management all play a role in a successful classification deployment. Before you reach this point, you should have a plan in place for rolling out your taxonomies. For example:
- Consider your approach for rolling out your categories. You may want to bring categories online slowly to carefully review the results, or you may want to deploy an entire taxonomy at once so that business owners can make informed decisions when working with their categorizations.
- Data Governance administrators should consider what data to begin classifying. Start with data that you understand, as it will help you verify the accuracy of the system. You can scale out scanning as you understand the network and computing load of classification.
- Classification analysts should design taxonomies should serve a single purpose. For example, if you require both Personal Health Information (PHI) and Payment Card Industry (PCI) taxonomies, they should be separate taxonomies, not branches of the same one. This allows users to manually override within an individual taxonomy, and continue to have the system automatically categorize within other taxonomies.
- Compliance officers should consider when policies and attestations that use the results of categorizations will be rolled out. Business Owners and Compliance Officers will see violations on published categories referenced by policies and attestations.
- In order to ensure that the system has the intended results, you should consider the communication and education strategy that you will use to accompany initial and subsequent deployments.
- The timing of changes should be considered. It takes time for new categories and changes to existing categories to flow through the system, depending on the volume of data, and the scan schedule. During this time, it is possible that business owners may manually apply a category they think appropriate, which will prevent further automated classifications for that taxonomy.
- A workflow for deployment should be planned. See Deploying a Taxonomy for more information.
Deploying a Taxonomy
Before you begin deploying a taxonomy that is intended for use by business owners to help secure your unstructured data, you should have a workflow in place for managing updates. Once a category is in production, changes should be handled carefully, so as not to unnecessarily disrupt the business owner’s interaction with the system, and to continually ensure that actual categorizations and resulting work flows in your organization are reflective of your needs.
 |
It is possible that modifying categories, rules and extractors in the production environment can have unintended results. Increased policy violations, changes to categorizations on owned resources, and more required attestations can occur. Reports may be inaccurate and business owners may end up spending time dealing with the unexpected results of a change. |
When you make changes to the production environment, all scanned resources are subject to the change. Although you can make changes in the production environment, it is not recommended. Instead, you should maintain a separate Data Governance server with test copies of your taxonomies.
There are a number of things that you may need to modify over time, and each has its own considerations.
| Modification | Consideration |
| Adding a taxonomy or category | New categories should be fully tested before you bring them online, and monitored closely once categorization begins. See Creating a Taxonomy and Creating a Category. |
| Modifying a category: changing its properties or adding/removing rules | Significant changes to categorizations can result from what might seem like a simple change. See Editing a Category for details on the impact of changing properties, and Associating Rules to Categories. |
| Removing a category | You should only delete categories once you have ensured that the category is not referenced elsewhere in the system. If desired, you can unpublish a category. Business owners will not see any categorizations using this category, and no new categorizations can be made using it. Existing categorizations can be viewed by classification analysts only. Once a category has been published, it is not recommended that you unpublish a category to do further development work on it, as this will likely cause confusion for business owners when categorizations are not shown. Once a category is unpublished, you should either leave it that way or delete it. Instead, use your test environment for category development. |
| Modifying or removing a rule | Rules can be shared across multiple categories, spanning more than one taxonomy. Because of this, a change to a rule can have a wide reaching impact on categorization. It is important to test changes on all impacted categories before implementing the rule change on a production taxonomy. For more information see Implementing Rules for Automated Categorization. |
| Modifying an extractor | Extractors can be shared across multiple rules, which can affect multiple categories and taxonomies. Because of this, a change to an extractor can have a wide reaching impact on categorization. It is important to test changes on all impacted categories before implementing the extractor change on a production taxonomy. For more information, see Working With Extractors. |