The FIRST step would be for us to define our security strategy, we would then use that to make our security policies, and baselines, we may use best practices for our industry as well.

Everything we do in Information Security refers back to the business goals and strategy. Since the question was what we do FIRST when developing an IS plan, we need to know the business strategy, goals and vision. The BIA, vulnerabilities and awareness is something we would look at much later.

NAT is the only option that may help us against external security threats. Local IP addresses are not routable. Using static Is would really do nothing, background checks would be for our internal employees, and the WORM media may prevent the attacker from deleting the logs, it will do nothing to protect us against attackers.

Of the options available here, role-based access control would protect our information from internal threats the BEST. A privacy policy is not related to risk, defense in depth is mostly focused on outsider threats and audit trails is detective controls we use after the fact.

We would isolate the affected networking segments FIRST, we need to contain the attack and ensure it does not spread. The rest of our network can keep functioning, but with heightened monitoring. We would never just shut off all external access, we would segment FIRST, and only as a very last resort shut external access. Logging should already be enabled, and it should write to a centralized logging server as well as WORM media. During an attack we have more important things to worry about than enabling logging, it should have been done when we moved the system into our production environment.

We FIRST need to confirm it is a real patch from the actual company that made the software. We do this before anything else. If we confirm it is from the company that made the software and it is critical, we would do proper change management, and if the patch was approved, we would deploy to our test environment first. If no issues we would either do another change management or deploy to production. It is very unlikely we would do (or be able to) do any code review of a patch.

The data owner would be responsible for determining the level of security required, the classification of the data, and who has access to it. The patches, deploying security controls, and moving updated applications from development to production would be performed by different data custodians.

The threat landscape is constantly changing and with that the risk we have to protect against. While previous risk assessments may not be accurate it is not the MOST important reason to do it, neither would optimizing, that is an added bonus. We would never do a risk assessment just to prove we are needed, we do that by giving valuable information that senior management can act on.

Of the answer options the PRIMARY goal of our risk management program is to minimize our residual risk. We can never eliminate business risk completely. We may not be able to minimize inherent risk. We want to implement effective controls, but we do that to minimize residual risk.

We should address risk as early on in the project as possible, of the phases listed here that would be feasibility. In the programming or the user testing phase is way too late, if the feasibility phase was not an option, then we would do it in specifications, but feasibility is much better.