Below are some legal aspects that should be kept in mind when implementing Traceability into any services. While this section is not legal advice, and does pretend to cover any or all legal implications of software development; it was written with the intent that there are aspects that should be kept in mind. As always, you should consult your compliance department / legal team if you have any specific questions about these subjects.
A significant advantage to Traceability is that it allows an organization's compliance department to more easily verify how specific pieces of software are implemented. This ability allows them to better ensure they are following any regulatory or contractual agreements correctly.
A very important point to remember in this discussion is that any data that is used in a service call will show up in the Traceable stream. It is very important to set up policies about sensitive data, and how they appear in the Traceable output. If too much data is shown, and the Traceable output is viewed by unauthorized personnel, then your company may have a liability issue. On the other hand, you may need to have the ability to test and / or troubleshoot issues around the sensitive data.
As outlined in Code Generation, it is possible to mask out specific fields automatically. Another variation might be to have a flag in the Tracer that turns masking on and off. If you go with the flag method, then the default value should cause the masking to be enabled.
As pointed out before, one of the major design requirements that the Traceability was not placed on the production servers. While the primary purpose of that requirement was for perfomance; another reason is safety. It is a not uncommon error to see a processing error return a stack trace to an end user. This type of information is very useful to bad actors. If the Traceability information was also provided in this situation, then even more useful info will be provided.