Generally speaking, there are two types of events that would require that CopyStorm, Restore or Medic be shut down while CS:Govern is being used.  The first is when the Table/Field rules are being added or removed.  Those changes are not reflected in the CopyStorm, Restore or Medic sessions until they are re-started.  For example, Medic will prevent a user from dropping any table that has at least one Governed field.  However, if a new field is added to Govern protection while Medic is already started, then the user will be able to drop the table that contains that field.  It is only when Medic is restarted that it will know that the table should not be able to be removed.

The second event is when a Custodian is being executed.  Restore should definitely be shut down if any of the tables being restored back to Salesforce are under CS:Govern protection.  And, depending upon what task is being executed in Medic, that, too, would need to be shut down.  For example, if one is running a Restore session, and an Encryption Custodian is executing in CS:Govern, until that Custodian has completed, it is possible that some of the records in tables being restored have not yet been encrypted and masked, as it takes the Custodian a non-zero amount of time to protected those records.  In that case one risks restoring unprotected data back into Salesforce.  Whether this is a problem or not depends upon the use case.  In the case of Restore, it also depends upon whether the objects being restored are under CS:Govern protection or not.  Similarly, depending upon which Medic tool is being applied, similar discrepencies can occur.  For example, if the Base64 Export tool of Medic is being used, and an Encryption Custodian is executing, some of the files dumped to the file system will be protected and others will not.

The same argument holds true for changes to the masking rules, user and role privileges or compliance categories.  Depending upon how much data resides in the CoyStorm database and what activities are being conducted in CopyStorm, Restore or Medic, one may see transient results in the data which may lead to unexpected data discrepencies.

As an example, let us suppose that one is using the Restore Set Editor in Restore and previewing data for Account records.  Let us also suppose that the BillingStreets field of those records are being protected by CS:Govern using an Asterisks masking rule.  And, finally, let us suppose that inside of CS:Govern a user is changing the masking rule for that field from Asterisks to Blank.  It is conceivable that when previewing the data in Restore, some of the records will appear as asterisks, while others will appear as blank.  If one is restoring the data back into Salesforce, it is possible that some of the Account records will restore the BillingStreet with asterisk values while other records are blank.

As a rule of thumb, it is safest to shut down all CopyStorm, Restore and Medic sessions while changes are being made to CS:Govern.