Communication Surveillance Policy analyzes a document and, based on the content, scores a document according to a preselected and customizable score. Once the conditions of the policy or rule have been met and an event is captured, it is reviewed by a person who will determine if a violation has occurred. If the conditions of the policy were met but the event contains language that is not pertinent to the intent of the policy, the event is placed in a queue to be reviewed by a policy refinement technician. This technician analyzes the event and refines the policy in order to prevent the event, or any similar event, from being captured. Policy/Rule refinement is a necessary and ongoing process as the criteria for what is and isn’t a violation are constantly evolving.

A communication surveillance policy technician goes through the refinement queue with a preferable date range set to only show the past 2 weeks’ worth of events. This ensures that the events displayed are events that were still captured after the latest round of refinements because events older than a week might have already been refined out.

Alternatively, the events that require refinement are compiled by the client and sent to Technically Creative for the purpose of review and context.

Refinement notes are recorded in a Notepad++ document, based on the events viewed. The format for the document is as follows.

• Policy or rule name.
• Line to be added, deleted, or changed.
• Production EventID that references the event that the refinement applies to, and the one it is tested against followed by a brief explanation of the intent of the line.

Once the queue has been cleared and the events have been marked with an audit status to reflect that, apply the refinement changes noted in the Notepad++ document to the policies in a development environment.

Development Imports:

• The first import that is done is against production data. This is done to ensure that there are no syntax errors present in the new round of refinements.
• If a syntax error is present, this is corrected in the Notepad++ document and in development.
• Once it is confirmed that there are no syntax errors, run an import of the events that were downloaded into the separate drive connected to a CMS to ensure that none are captured.
• If events are captured, further refinements are made and added to the Notepad document
• When it’s confirmed that there are no syntax errors and there are no events that are captured, the changes are moved to UAT.

The UAT environment is constantly updated to mirror production. This includes policies, hierarchy, user attributes, settings, communication surveillance policy roles, policy classes, security models, user roles, and patches that have been applied to production.

From the development environment, the changes are then moved into UAT. This is done by copying and pasting the changes from the Notepad++ document.

The configuration file is updated to reflect the date range that was covered by the refinement queue.

To ensure the most accurate test of the changes, all of the policies or rules that are enabled in production are enabled in UAT. This is to see how the policies behave together.

• The changes are run against production data that is imported via SQL import.
• The activity log, performance monitor (items processed per second), hit ratio (Captured:Processed), event import log, and windows logs are all checked to verify that there are no errors or erroneous results.
• If there are errors, these corrections are made to the Notepad++ document to modify the strings.

Once it’s been confirmed that there are no errors present, the captured events are reviewed to determine the quality of what the policies have captured.

• Any additional last-minute refinements are made and added to the Notepad++ document.
• These are typically minor changes (enhancements to current changes) that are tested right in UAT rather than development.
• Any major changes (syntax changes, added lines, changes to current strings) are tested in development and follow the same testing guidelines as previously outlined.

Once it is confirmed that there are no errors, the lines added successfully refine out the events, and there was no significant impact to the integrity of the policies or rules, the changes are then documented in a Policy Refinement Document.

This document outlines the granular details in an easy to read format for reference, release, and compliance purposes.

The refinement document is then sent to the individual designated to do the release to double check and confirm that the changes in the document match what’s in UAT.

Once the review is complete, the document is then sent to the requesting bodies for approval.

Change Request: Each Client varies; however, we work with the client through the approvals that need to be attained before a release to production.

Release: The changes are released to production by a designated individual. After all the changes are released, they verify that there are no errors reported in the activity log.

The refinement document is delivered to the client for archiving purposes. An XML export is taken to reference for rollback purposes for the next release. A copy of the refinement document is archived to a Technically Creative directory.