So we have to approach this and determine how we can best make sure we remain in compliance and address these various issues. Now, compliance enforcement ensures that the organization's guidance documents are being followed. These of course must be driven by the needs of top management, regulatory requirements, or industry requirements.

Our enforcement procedures should enforce these through various kinds of procedures drawn from and made compliant with the external regulatory sources where applicable. For example, a procedure that help desk personnel follows when resetting passwords may involve various aspects, such as verifying the identity of the caller through specific means, making sure that they track the transaction all the way through up to and including the change by the person at the other end, and then documenting exactly what they've done so that if there ever turns out to be a discrepancy, they'll be able to track it back to its source.

The enforcement then would be that the supervisor will periodically listen in on a phone call to see if this procedure is being followed and then examine the documentation from it to ensure that all things necessary are captured. Now, we have to remember that procedures should derive directly from the high-level policy to ensure that the metrics as specified by the policy are in fact being attained.

Undoubtedly, there will be from time to time policy exceptions. And because the world can be uncertain and not every condition mirrors every other condition, we have to expect these. Now, departments can request exceptions to existing policy, but there should be a process through which they formally place rigor over this to ensure that the exceptions truly are exceptions and are properly handled up to and including all documentation.

In the case of submitting something to be considered for an allowed exception, the request that is submitted is going to be weighted based on the risk reward and a potential exposure that might result from allowing it. Standards provide options for remaining in compliance with policy.

Procedures must and often do reference various standards of performance or other kinds of metrics that gauge whether or not the goals have been achieved even if by alternate routes. Also, providing an economy of scale to map a policy to a standard only once is a way of ensuring that we are taking the least cost, but optimal approach.

There should of course be a toolbox that gives us the way to make sure that we can detect when we're not in compliance and when we have crossed back over into a compliant state. Some of these tools will be normal monitoring, periodic auditing and their reports, a security review as different and distinct from an audit, a vulnerability scan, or for that matter a penetration test, and the documentation generated through our due diligence work.

Compliance enforcement is like all things not ending and it is shared across the entire organization. The security program itself should in fact be audited to determine how it complies and how it enforces compliance throughout the organization. The results are often expressed in the form of risk or mitigating factors, acceptable control objectives, and a measurement of the cost-effectiveness of the tools and techniques chosen to create and implement the program.

Inherent in all of these will be an assessment of risk and impact. And this is specifically the vulnerability assessment. We should have monitoring in place to continually assess whether our systems, especially those highly automated ones, that there is some form of vulnerability detection to enable remediation.

One of the things we should be looking for would be unexpected changes to systems and their sources and causes. An example might be changes to the Windows Registry outside of a maintenance window. As part of our change management of course, we should have a fairly strict schedule of how these are going to be done and what order of magnitude will require what sort of supporting staff so that we have good rigor applied to the process as well as the documentation that has to be generated from it.

Next, we have our assessment of risk impact through threat assessment. Now, a continuous assessment model can be costly. So what we should do is periodic reassess the attackers and vulnerabilities from the various authoritative sources that we have at our disposal. For example, threat sources are typically from tactical, human, physical, natural and environmental, or other sorts of sources such as pandemics. And in the case of discovering a particular threat, we need to consider the reality and the relevance of it.

We, of course, need to consider what the probability of impact is going to be. And in this case, we're talking probability, not possibility. We have to consider the order of magnitude that the impact may have. And, of course, what is the impact point? What assets will be affected by it when it materializes?

So through this process, we look at risk assessment and business impact analysis. Now, recall what I said a little while ago. A business impact analysis and a risk assessment are compliments to each other, not substitutes for each other because they have different objectives.

The business impact analysis looks at the impact of losing resource availability. It looks at escalation of loss over time. It identifies the resources needed to recover and prioritize this one as opposed to another one. But in the end, it's looking at the actual business impact of an outage event.

A risk assessment is mostly concerned with the type and order of magnitude and probability of occurrence of a threat that can cause a material loss. The key word here may be impact where the level, meaning a combination of type and order of magnitude of an impact is at the heart of a risk assessment. But the risk assessment itself is not looking at the actual business effect. It is looking more at the impact of the event and the negative results that can be caused by it.

Most disasters are not the result of a single event, but from several small ones. There will of course be residual risks in the aggregate that can be disastrous, whereas any one of them may not itself be all that dangerous. We have to continuously communicate the effect of emerging risks to stakeholders. It can be on once a year or it can be carried out on a more often periodic basis.

Again, part of our assessment of risk impact would be resource dependency assessment. Now, this can be an attractive alternative if you're not able to do a complete business impact analysis. What this will do is this will look at specific business functions. For the most important of these, it figures out which resources are critical for that function to be properly carried out, such that if it were deprived of these resources, it would fail and what it subsequent impact of failure would be. What this leads to though is more of a general assessment of what the impact would be rather than a detailed one because that's what a BIA does and we do this as an interim step to achieving a full BIA.

Now, part of this will be assessing our supply chain, which talks about outsourcing and our service providers. Essentially, we have two different forms of outsourcing. We have third parties which provide security services and then we have other outsource processes that must be integrated into the security program.

Obviously, this is from the security perspective as opposed to a straight operational perspective of the business as a whole. Now, each of these options will have a different owner. The risk involved in the external organization is going to have access to our internal network.

Despite the risk that is associated with this, outsourcing can still be cheap enough to be of a benefit as long as we can properly offset the risks that may be associated with it. And the value of the outsourcing may never really materialize. Examining this as we might with many different aspects, the total cost of ownership can help us determine or at least get closer to what the actual material value of this outsourcing will be. 

Now, as part of this evaluation, we have to consider what the impacts might also be. For example, the company might lose essential skills moving from the company to the outsource. There might be a lack of visibility into the security and protective value provided by the outsource.

There may be new risks to assess. The long-term viability of this arrangement has to be periodically reviewed as well because now we have additional exposure, additional attack surface you might say. It adds increased complexity to incident management, whether it happens at the company or at its outsource, because it is still the company's assets that are being targeted but now we have double the amount of players involved.

There's also the question of cultural and ethical differences that may exist between the outsource and its employing company. And these need to be folded into the overall assessment. Undoubtedly, there will from time to time be unanticipated costs and service shortcomings which may be experienced by the company without the outsource, and yet are viewed in a different way, such as inconveniences where here service interruptions can be seen as critical.

Now, outsourcing and service providers also need to be audited periodically before the contract as part of the due diligence before bringing them on board and then during the contract to ensure that our goals and objectives, our deliverables and schedules are being met. We can do it either by our own staff or having an external auditor perform them.

Anytime there is individually identifiable information involved, laws regarding privacy will need to be included and obeyed. Such laws also need to be captured in proper language in our service agreements with these outsourced providers.

No doubt, we will have to ensure proper processes and procedures are taking place, but we will have to do it through the vehicle of the contract, as opposed to assuming greater agency, that is more internal involvement of our company with our outsource and their management processes. And so visibility may be reduced and that in itself is a risk that must be addressed.

We have to, of course, pay special attention to the level at which the vendor meets our standards. So in looking at these vendors, the maturity of the vendor security program must be equal to the standards that we set for it, or it must be elevated to that level, or we need to select a different vendor. They must be risk neutral to us, such that our compliance assurance is not affected negatively, but in fact should be affected positively by our choice of vendor, which means their compliance must be equally high.

Most of this will be carried out through the value of the wording of our contract. Now, the purpose of a contract basically says who's going to do what for whom, how it's going to be delivered, all the particulars of that, and how it's going to get paid for. Also part of the contract will be how to handle disagreements and disputes.

There must be provisions that address confidentiality and nondisclosure where any sort of privacy-covered information or any proprietary information will be involved. Specified within the contract language should be information regarding retention times or disposal times or destruction times.

The methods of disposal should also be equally clear. The contract should state that the controls are to be maintained and in the case of particular needs which controls will be used. Part of the contract should be that the company employing the outsource has the right to audit and the right to inspect. And these should be provisions written into standard language and included in every third-party contract.

Now, the right to audit would be that the customer can initiate an audit if sufficient notice is given to the vendor either itself or through a party that it elects to hire. The right to inspect may mean that there is no notice given and it's done as a spot check without announcement, but both of these will have to have proper contractual language written around them.

The contract also needs to specify very clearly the role of each party should there be a breach, who's going to do the investigation, what the timeframe will be for learning, how the response will be handled and so on. And as a result of all of these, special attention must be given to the indemnity clauses to see who is covering whom from what.

This is basically put in place to protect each party from things and losses for which they have no responsibility and no involvement. The providers can write contracts to favor them, but the entity employing the provider needs to be sure that they understand exactly what they mean and that they're in agreement with them before it's included in the final signed contract version.

Third-party access will always need to be addressed within the context of each contract. What information, what systems, what facilities, whether it's electronic or physical, the access always needs to be controlled and monitored and provided on the basis of lease privilege and need-to-know for the role of the individual concerned.

All usage needs to be logged in a frequency based on criticality of information, criticality of privileges, length of contract, and other factors. In the end, we don't grant access until the contract is signed, of course, but when access is granted, it always must be commensurate with the requirements due to the function of the individual for whom the access is being considered. Just as important will be the removal of the access when the contract is terminated or when any employee under the contract is terminated.