Information Security Policy and Security Activities · Professionals
1. Overview
A. Definition
The top-level document that codifies senior management's will and direction regarding information security for an organization; with it at the apex, guidelines, standards, and procedures are hierarchically derived, becoming the criterion that governs the security activities of the entire organization. A policy is the declaration of "what we protect and why," while the activities and professionals beneath it handle "how and by whom."
An information security policy is often mistaken for a technical document, but in essence it is a management decision-making document. This is because it declares "to what level, why, and by whom our organization protects its information assets." Concrete technologies such as firewalls and encryption are merely the means of realizing this declaration, and when and how to use those means is determined by the guidelines and procedures beneath the policy. Therefore a policy does not change frequently with technology trends — nor should it.
To understand information security as a single system, one must look together at the three axes of policy (what and why) → activities (how to operate) → professionals (who performs). The policy presents direction, security activities (the Security Action Cycle) execute that direction at each point in time, and security professionals are the parties who design and operate both. Only when these three axes mesh and turn together does an organization's security change from a "declaration on paper" into a "working system." Below, these three axes are examined in turn.
B. Background and Necessity
As an organization grows and its information assets increase, security controls cannot be left to individuals' discretion or to a person-in-charge's customary practice. If each department grants access rights by a different standard and incident response is improvised, gaps appear in the controls. That is why an information security policy pins down a consistent security standard and responsibility regime in a document so that all members follow it. Without a policy, departments respond differently to the same threat, and when an incident occurs there is no criterion to judge "who should have done what."
Moreover, laws and certifications such as ISMS-P, the Personal Information Protection Act, and the Credit Information Act require policy establishment as a mandatory obligation. In other words, a policy is not optional but the starting point of legal compliance and risk management. Externally, too, the existence and enforcement of a policy becomes evidence of trust to customers, partners, and regulators that "this organization manages security systematically." If the policy is poor, responsibility becomes unclear during an incident, legal liability is aggravated, and external trust is hard to recover.
Furthermore, a policy is also a device that formalizes an organization's risk appetite. Because making every risk zero is impossible and inefficient, an organization must decide "which risks to accept and to what extent, and from where to control, transfer (insure), or avoid them." If this decision-making criterion is codified in the policy, resources can be allocated by a consistent standard rather than judged improvisationally for each case.
C. Characteristics
An information security policy has three characteristics. First, apex position and stability. A policy sits at the top of the pyramid and is the basis for lower documents, so if it changes often the entire organization is shaken. Second, organization-wide applicability. It must apply equally not to a particular department but to all members and partners so that no blind spots appear in the controls. Third, enforceability and accountability. It specifies the compliance obligation and sanctions for violation so that it does not remain a declaration of "comply or not, it's all the same."
These three characteristics mesh with one another to uphold the policy's authority. Even with apex position, if it is not applied organization-wide, exceptions in some departments neutralize the entire control; and even if applied organization-wide, without enforceability members will not follow it. That is why a good policy, while holding abstract principles, clearly connects those principles down to "who, how, and with what accountability upon violation."
2. The Concept and Hierarchy of an Information Security Policy
flowchart TB
P["Information security policy<br/>top-level directive & management will"] --> S["Guidelines & standards<br/>field-specific criteria"]
S --> G["Procedures & guides<br/>concrete execution methods"]
P -. basis .-> LAW["Laws, regulations, certifications (ISMS-P, etc.)"]
A policy document has a pyramid structure that becomes more detailed as it descends from abstract direction (policy) to concrete execution (procedures). The top-level policy holds the principle "this is how we protect information" and management's will, and it rarely changes. Beneath it, guidelines and standards set field-specific criteria such as access control, encryption, and password management, and at the bottom, procedures and guides specify practical steps such as "how an account is issued in this system" and are updated frequently as circumstances change.
The reason for dividing the layers this way is to separate the scope of change's impact so that the frequently changing detailed procedures do not shake even the top-level principles. For example, changing a password from 8 to 12 characters is sufficient with only a revision of the standard and procedure, while the policy principle "we control access" remains the same. If such details were written directly into the policy, every small change would require management approval again, paralyzing document management. Conversely, lower documents must maintain consistency with upper documents, and a procedure that contradicts an upper principle has no effect.
The hierarchical structure gives another benefit, traceability. One must be able to trace, from bottom to top, why a particular control exists all the way up to the upper policy and laws, in order to answer "what is the basis for this control" during an audit. Conversely, descending from top to bottom to verify "by what procedure this policy principle is actually implemented" allows one to discover gaps in enforcement. In other words, a well-designed document system is connected in both directions so that there is no broken link between principle and execution.
For a policy to be effective, official approval and support from management are essential. A policy entails budget, personnel, and organizational authority, which only management can allocate. A policy signed by management becomes the source of authority that makes it impossible for any department in the organization to refuse security requirements. When a security officer requires a particular control of a sales department, having the basis "this is an organization-wide policy approved by the CEO" can overcome resistance, but without such authority the control is repeatedly pushed aside by work convenience. This is the practical reason management approval must always be included in a policy.
Also, because the threat environment keeps changing, the policy must be periodically reviewed and updated at least once a year and whenever there is a significant organizational or technological change. A policy made once and then left alone diverges from reality and actually obstructs the controls. For example, if the infrastructure was moved to the cloud but the policy is still written on an on-premises premise, members will ignore the policy or interpret it arbitrarily, breaking the consistency of the controls.
| Item | Content |
|---|---|
| Definition | Top-level document codifying the will and direction of information security |
| Hierarchy | Policy → guidelines/standards → procedures/guides |
| Requirements | Management approval and support, organization-wide application, periodic review and update |
| Content | Purpose and scope, roles and responsibilities, compliance and penalties, security principles |
Elements that a policy document must contain include purpose and scope of application, roles and responsibilities (R&R), compliance obligations and sanctions for violation, and core security principles (the policy for guaranteeing confidentiality, integrity, and availability). If these elements are missing, the policy remains a list of "nice words" and fails to become a criterion for judgment in an actual dispute or incident. It is especially important to write out roles and responsibilities clearly, because when an incident occurs, "who decides and who executes" must be set in advance for response to be possible without confusion.
3. Activities by Security Time Point (Security Action Cycle)
flowchart LR
D["Deterrence"] --> P["Prevention"]
P --> DT["Detection"]
DT --> R["Response"]
R --> RC["Recovery"]
RC -. lessons learned .-> P
Security should be viewed not as a one-time measure but as a cycle encompassing before, during, and after the point of an incident. The reason this perspective matters is the reality that no matter how much prevention is strengthened, breaches cannot be blocked 100%. If one invests only in prevention, one is defenseless "after being breached," so resources must also be distributed to detection, response, and recovery to minimize overall damage. Each stage is not independent; they are connected in a feedback loop in which the lessons of the recovery stage again strengthen prevention.
The perspective of seeing these five stages as one cycle becomes a framework for judging where and how much to allocate security investment. If budget is concentrated only on prevention, detection and response "after being breached" become poor, and conversely if one concentrates only on incident response, one fails to reduce the frequency of breaches in the first place. A balanced organization allocates resources evenly across the five stages while adjusting the weighting according to the importance of the asset and the shape of the threat.
Deterrence psychologically blocks the very attempt at an attack or an insider violation by giving notice of penalty provisions and the fact of monitoring. A mere notice that "all access is logged and violations are disciplined" reduces insider deviance. Its characteristic is that it is the lowest-cost control. Prevention blocks breaches in advance through access control, encryption, and security training. It is the most ideal but has the limit that it cannot be perfect in the face of unknown vulnerabilities (zero-days) or sophisticated social engineering. That is why prevention takes as its realistic goal not "making breaches zero" but "raising the cost of a breach high enough that the attacker gives up."
Detection rapidly discovers breaches that have already occurred through IDS, SIEM, and log monitoring. As the defensive line after prevention is breached, "how quickly a breach is noticed" determines the scale of the damage, because if a breach goes unnoticed for months, the damage snowballs. In fact, in many large leakage incidents the detection delay (dwell time) has enlarged the damage more than the breach itself, so reducing the average detection time is highly cost-effective. Response prevents the spread of damage through isolation, blocking, and root-cause investigation upon confirming a breach, and preserves legal and forensic evidence without impairment. If response is clumsy and evidence is overwritten, both root-cause identification and legal response become difficult.
Recovery normalizes systems with backups, secures business continuity with BCP/DRP, and reflects recurrence-prevention measures. At this point, the core of the cycle is to analyze "what was breached and why" and feed it back to the prevention stage. Without this feedback, the same type of incident repeats, and the organization pays the same cost each time. Ultimately, the maturity of security activities is gauged less by the strength of individual stages than by how tightly the cycle turns.
| Time point | Example activity | Nature |
|---|---|---|
| Deterrence | Policy/penalty notice, monitoring notice | Before, psychological |
| Prevention | Access control, encryption, training | Before, technical |
| Detection | IDS/SIEM, log monitoring | During |
| Response | Incident isolation, blocking, investigation | During, after |
| Recovery | Backup restoration, BCP, recurrence prevention | After |
This cycle model serves as a bridge that translates the policy's "security principles" into concrete activities. For example, if the policy declares "information assets are protected according to importance," then at the activity stage the more important the asset, the more thickly prevention, detection, and response are arranged. Conversely, a vulnerability that repeatedly surfaces in activities becomes a signal demanding supplementation of the policy and guidelines. In other words, policy and activities are not a one-way top-down relationship but a two-way relationship that corrects each other, and the security professional takes the role of connecting the two.
4. The Role and Competencies of Information Security Professionals
Information security professionals (e.g., the CISO and security officers) are the parties who actually design and operate the above policy and activity cycle. No matter how well a policy is written, if there is no one to weave it into the field and command during an incident, the document remains mere paper. That is why the professional's competency determines the upper bound of the organization's security level.
In particular, today security is not complete through technology alone. When an incident occurs, the professional must explain the damage and response to management, judge legal obligations together with the legal team, coordinate external messaging together with PR, and report to regulators. In other words, technical, managerial, and soft competencies are required as a trinity. A professional who is technically outstanding but cannot communicate easily lets the golden time of incident response slip away amid confusion within the organization.
The professional's role becomes clearer when divided into peacetime and emergency. In peacetime, they maintain policies and guidelines, identify and assess risks to select controls, and maintain the effectiveness of controls through vulnerability inspections, training, and audits. In an emergency (incident occurrence), as the incident-response control tower, they command isolation, investigation, and recovery and coordinate stakeholder communication. If peacetime preparation is poor, emergency response will surely waver, so the professional's true ability is revealed in the steady management when there is no incident.
For example, when a ransomware incident occurs, the professional (1) technically analyzes the infection route with forensics and blocks the spread, (2) managerially carries out the procedures for breach reporting, management briefing, and setting recovery priorities, and (3) with soft competency explains the situation to employees and conducts recurrence-prevention training. Only when these three competencies operate simultaneously can damage be minimized.
The position within the organization (the reporting line) also governs the professional's effectiveness. If the CISO is subordinated under the head of the IT department, security tends to lose out in the conflict of interest between "availability/development speed" and "security." That is why many organizations design the CISO's independence higher so that they report directly to management and the board. This also touches on the legal and certification requirements emphasizing the independence of the protection officer, and ultimately it is the question of "in whose voice security is conveyed to management."
| Category | Competency |
|---|---|
| Role | Policy establishment, risk management, incident response, security operation/audit, awareness training |
| Technical competency | System, network, cryptography, and cloud security, digital forensics |
| Managerial competency | Governance and compliance (ISMS-P), risk management |
| Soft competency | Communication, professional ethics, continuous learning of the latest threats |
It is important that none of the three competencies can be substituted by another. Technical competency is the foundation for understanding and blocking threats but cannot move the organization; managerial competency institutionalizes controls but rings hollow without knowing the technical reality on the ground; and soft competency connects the former two to the organization's decision-making. That is why a security professional's growth is achieved not by deepening in a particular field alone but by the balanced expansion of the three competencies. Professional ethics is especially worth emphasizing, because a professional has the authority to access the organization's most sensitive information, so the ethics of self-controlling the misuse of that authority become the premise of all technical controls.
5. Comparison of Policy, Guidelines, and Procedures and Application Cases
Policy, guidelines, and procedures are layers of the same security system but differ in purpose and change cycle. Confusing this difference leads to writing detailed procedures into the policy and making the document rigid, or conversely scattering principles into procedures and losing consistency. The key is to divide the layers by "how often it changes" and "who approves it." Many organizations fail to distinguish these three layers and cram everything from password length to firewall rules into a hundreds-of-pages "policy," creating a document no one reads. Conversely, a mature organization keeps the policy short and stable and absorbs change in the lower documents.
| Category | Policy | Guidelines/standards | Procedures |
|---|---|---|---|
| Nature | Principle and direction | Field-specific concrete criteria | Step-by-step execution method |
| Change cycle | Nearly unchanging | Medium-term update | Ad hoc update |
| Approval authority | Management | Security officer | Practical manager |
| Example | "Information is protected according to importance" | "Confidential information is encrypted with AES-256" | "The order of work for issuing and revoking encryption keys" |
As concrete cases: (1) when a financial firm was investigated after a personal information leakage incident, an organization whose policy, guidelines, and procedures were hierarchically maintained quickly identified "which control failed and where" and proved its accountability, whereas an organization with mixed-up documents had delayed response and aggravated fines. (2) When remote work spread, a case of leaving the access-control "principle (policy)" intact while rapidly updating only the VPN and endpoint-security "procedures" to respond demonstrates the practical benefit of layer separation. (3) Between an organization that left security training as a "formal annual completion" and one that operated it with "phishing drills + result feedback," the case in which the latter's actual phishing click rate dropped to a fraction demonstrates that a policy's effectiveness hinges on enforcement.
The lesson running through these cases is that the value of a policy system is revealed not in normal times but in the moment of an incident or a change. When things are calm, the difference between a well-maintained document and a jumbled one is invisible, but when a leakage incident, a regulatory investigation, or a sudden change in the work environment strikes, that difference appears starkly in the speed of response and the size of legal liability. Therefore maintaining policies is an investment that must be done proactively "even if it seems to have no immediate effect," and it has the character of insurance.
6. Advanced — Zero Trust, Governance, and Linkage with Past Exam Questions
Traditional security was a model that divided "a trusted internal network" and "a dangerous exterior" by a perimeter. However, as the cloud, remote work, and mobile became universal, the boundary between inside and outside disappeared, and incidents in which an attacker who entered the inside once moved laterally at will occurred frequently. In response, the paradigm is shifting to Zero Trust, which "never trusts and always verifies." Zero trust verifies the user, device, and context on every access and grants least privilege, which can be understood as making the "prevention and detection" of the security activity cycle constant.
What is important is that zero trust does not replace the existing policy system but updates the security principles that the policy must hold. If one changes the implicit premise "the inside is trusted" to "all access is verified," then access-control standards and authentication procedures must be rewritten according to that principle. In other words, the introduction of zero trust is policy-amendment work before it is technology introduction, and it succeeds only when management approval and a phased implementation plan go together. In this way, a paradigm change must propagate from the top of the policy pyramid down to the bottom to maintain consistency.
From a governance perspective, there is a clear trend of the policy being integrated as part of the organization-wide risk management system. Security is treated not as a technical issue of the IT department but as a board-level management risk, and certifications such as ISMS-P and internal controls continuously verify the enforcement of the policy. Recently, the very scope the policy must address is expanding — supply-chain security (partners, open source), data protection due to AI use, the cloud shared-responsibility model, and so on — so the need for periodic policy updates is growing even greater.
In terms of past exam questions and related topics, this topic is closely linked with ISMS-P certification, risk management (risk identification, assessment, response), BCP/DRP, zero trust, and the role of the CISO, so in an answer, weaving the flow of "policy establishment → risk-based control selection → operation via the activity cycle → continuous improvement" can show depth. Expected exam directions include "a plan for establishing an information security policy in the zero-trust era," "security governance and the role of the CISO," and "a breach-incident response system from the Security Action Cycle perspective." When writing, the key to a high score is to avoid a mere listing of concepts and to show how the three axes of policy → activities → professionals are integrated into one security management system.
7. Considerations and Implications (Professional Engineer's Perspective)
- Success condition — not documentation but enforcement: A policy does not end with documentation alone. It is effective only when backed by management's will + organization-wide execution (training, inspection, drills). An unenforced policy instead becomes an aggravating factor of "knowingly not complying" during an audit.
- Balance and evolution: Maintain technical, managerial, and physical security in balance, but evolve beyond the limits of perimeter-based defense toward zero trust. However, since zero trust is not a single product but an architectural shift, the trade-off between phased introduction and user convenience must be managed.
- Continuity and feedback: Security is not a one-off project but a continuous activity of keeping the cycle (Action Cycle) from deterrence to recovery turning. The organization's security maturity rises only when the lessons of the recovery stage and threat intelligence are fed back into the policy and controls.
- Alignment of security and business: Excessive controls lower work productivity and induce "shadow IT." The policy must differentiate the protection level according to asset importance (risk-based) and design the balance between security and business agility.
- Importance of the human factor: No matter how sophisticated the technical controls, the final line of defense is people. Awareness training and the settling of a security culture decide the success or failure of policy enforcement.
- Measurement and improvement: A policy's effect must be measured to be managed. Deciding on security metrics (KPIs) such as the number of incidents, the average detection/response time, the training completion rate, and the drill click rate, tracking them periodically, and reflecting the results in the improvement of policy and controls — this data-based management is a characteristic of mature security governance.
- Supply-chain and third-party risk: The boundary of controls does not stay inside the organization. As breaches through partners, the cloud, and open source increase, the policy must encompass security requirements for third parties, contractual clauses, and periodic inspection. If only the inside is solid and the supply chain is loose, the weakest partner becomes the entry point for the whole.
References
- Korea Internet & Security Agency (KISA), ISMS-P certification criteria guide, https://isms.kisa.or.kr
- NIST, SP 800-207 Zero Trust Architecture, https://csrc.nist.gov/pubs/sp/800/207/final
- Personal Information Protection Commission, Personal Information Protection Act and safety-securing-measure standards, https://www.pipc.go.kr
- ISO/IEC 27001:2022 Information security management systems, https://www.iso.org/standard/27001
In one line: An information security policy codifies management's will as the top-level document (policy → guidelines → procedures) to set a consistent security standard, security activities are performed as a cycle of deterrence, prevention, detection, response, and recovery, and security professionals design and operate these with technical, managerial, and ethical competencies, evolving them toward zero trust.