Content (updated 2025.05)
- | Major Updates You Should Know | 務必知悉的改動
- | Different Types of SRA or SA for different SDLC stages | 不同 SDLC 階段行不同的 SRA / SA
- | SRA vs SA | SRA 與 SA 的差異
- | Difference in Major Deliverable Reports | SRA 與 SA 主報告的差異
- | Back to SRAA main page to continue SRAA full view | 回 SRAA 主頁繼續 SRAA 全面睇

Major Updates You Should Know
- #1. Confirmation of your Information-System-Tier – different system-tier has different security protection requirements
- #2. Confirmation of your Data Classification – different data-type has different security protection requirements
- #3 Get Ready of the IT Inventory of your system before SRA / SA – for the additional deliverable report required – Asset Identification & Valuation results
- #4 SRAA is NOT all-in-one activity, read the next sections and choose the right service(s) of your need

Different Types of SRA or SA for different SDLC stages
Starting in revision 2.0, SRAA official guide IPSG-SM01 clearly states the difference of SRA and SA, and their applicability in different stage of SDLC (software development life cycle); as to assist readers to choose right SRAA activity at the right stage.

System Development Life Cycle (with modification for concept illustration)

SRA vs SA
IT Security Risk Assessment (SRA) is the process to identify, analyse and evaluate the security risks, and determine the mitigation measures to reduce the risks to an acceptable level.
IT Security Audit (SA) is the review process to ensure (i) security measures and configurations comply with IT security policies, standards, and requirements; (ii) IT security treatment recommendations are properly implemented, and risk is appropriately mitigated
| SRA (Security Risk Assessment) | SA (Security Audit) | |
|---|---|---|
| What is it? | The identification of threat and vulnerabilities, evaluation of the levels of risk involved, and determination of an acceptable level of risk and corresponding risk mitigation strategies | The processes to ascertain the effective implementation of security measures against the departmental IT security policies, standards, and other contractual or legal requirements |
| Focus | Focus on the risk perspective, assessment areas not necessarily related to security policies and standards | Focus on the compliance perspective, assess against security policies, standards or other pre-defined criteria |
| When | For a new information system, the security risk assessment is typically conducted at the beginning of the system development life cycle. For an existing system, the assessments shall be conducted on a regular basis throughout the system development life cycle or when major changes are made to the IT environment. | The security audit is an on-going process (conducted on a regular basis) to ensure that current security measures comply with departmental IT security policies, standards, and other contractual or legal requirements. |
| Conducted by | It can be a self-assessment by HKSARG B/D (Bureau / Department) or completed by an independent third party | Must be completed by an independent third party |
| Key deliverables | risk register & risk treatment measures SRA Report (see below) | compliance checklist & compliance result SA Report (see below) |

Difference in Major Deliverable Reports
| Security Risk Assessment (SRA) Report | Security Audit (SA) Report |
|---|---|
| 1. Introduction/Background information. | |
| 2. Executive summary. | |
| 3. Assessment scope, objectives, methodology, time frame and assumptions for what are and are not covered. | |
| 4. Current environment or system description with network diagrams, if any. | |
| 5. Security requirements. | |
| 6. Risk assessment team. | 6. Audit Team & Declaration of security auditor’s independence |
| 7. Summary of findings and recommendations. | 7. Summary of Findings |
| 8. Risk analysis results (recorded in the risk assessment form), including identified assets, threats, vulnerabilities and their impact, likelihood and risk levels with appropriate reasons. | 8. Details of tests and their results and findings. |
| 9. Recommended safeguards with cost/benefit analysis if more than one alternative, e.g. install defensive mechanisms or enhance existing security policy and procedures, etc. | 9. Recommendations and corrective actions based on the problem areas found, e.g. violation of security policy, misconfiguration, well-known and potential vulnerabilities, information leaks, unused services especially those default ones, and unused accounts and so on. |
| 10. Conclusions Annexes | |
| A. general control checklist | A. audit checklist |
| B. vulnerability scanning report | B. vulnerability scanning report |
| C. penetration testing report | C. penetration testing report |
| D. asset identification & valuation results | |
| Security Risk Assessment (SRA) Report | Security Audit (SA) Report |


You must be logged in to post a comment.