+Business Continuity & Disaster Recovery Policy
|
Business Continuity & Disaster Recovery Policy
Description
Mechanisms exist to establish a formal, documented Business Continuity and Disaster Recovery (BC/DR) policy that:
(1) Conveys executive management's intent;
(2) Provides organizational direction and expected behaviors;
(3) Is reviewed at least annually; and
(4) Is updated, as necessary, to adapt to evolving risks, threats and other changes that affect the organization.
Possible Solutions & Considerations
Micro-Small Business (<10 staff) / BLS Firm Size Classes 1-2
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ Executive-approved written policy with documented annual review
Small Business (10-49 staff) / BLS Firm Size Classes 3-4
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ Executive-approved written policy with documented annual review
∙ Policy acknowledgement tracking (e.g., HR onboarding records)
Medium Business (50-249 staff) / BLS Firm Size Classes 5-6
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) for policy lifecycle management
∙ Documented annual policy review with version control
Large Business (250-999 staff) / BLS Firm Size Classes 7-8
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ GRC solution (e.g., SCFConnect, Cyturus, SureCloud, SimpleRisk, Ignyte, ZenGRC, Galvanize, MetricStream, Archer, etc.) for policy lifecycle management
∙ Policy governance committee with formal annual review and approval workflow
∙ Automated policy attestation and acknowledgement tracking
Enterprise (> 1,000 staff) / BLS Firm Size Class 9
∙ Steering committee
∙ ComplianceForge - Security, Compliance & Resilience Program (SCRP) (https://complianceforge.com)
∙ Enterprise GRC platform (e.g., Cyturus, Archer, MetricStream, ServiceNow IRM) for policy lifecycle management
∙ Automated policy attestation, exception tracking and change history
∙ Annual executive approval and board-level reporting
SCR-CMM
Level 0 Not Performed
Practices are non-existent, based on the inability to demonstrate an implemented and operational capability. A reasonable person would conclude the control is not being performed.
Level 1 Performed Informally
SCR-CMM Level 1 criteria definitions are not available for this control:
▪ A reasonable person would conclude this control requires a structured process.
▪ At this level of maturity, the "ad hoc" nature of performing a capability informally would indicate the intent of the control is not met due to a lack of consistency and formality.
Level 2 Planned Tracked
Business Continuity & Disaster Recovery (BCD) capabilities are requirements-driven, but are not standardized across the entity (e.g., local/regional level consistency). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity.
▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are documented and maintained by process owners.
▪ IT and/or cybersecurity personnel work with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with BCD domain capabilities to address applicable statutory, regulatory and/or contractual requirements for Technology Assets, Applications, Services and/or Data (TAASD).
▪ Business Continuity / Disaster Recovery (BC/DR)-related controls are primarily administrative and preventative in nature (e.g., policies, standards and procedures & guidelines).
▪ BC/DR may be a defined function (e.g., team or department) or assigned as an additional duty to existing IT and/or cybersecurity personnel.
Level 3 Well Defined
Business Continuity & Disaster Recovery (BCD) capabilities are standardized across the entity for applicability to People, Processes, Technologies, Data and/or Facilities (PPTDF) to ensure consistency for Technology Assets, Applications, Services and/or Data (TAASD). Capability criteria associated with this control reasonably expect the following criteria to exist:
▪ Policies and standards associated with BCD domain capabilities are formally documented and centrally-managed by the entity's Governance, Risk & Compliance (GRC) team, or similar function.
▪ Standardized Operating Procedures (SOP) associated with BCD domain capabilities are well-documented and kept current by process owners.
▪ A Business Continuity & Disaster Recovery (BC/DR) team, or similar function, is appropriately staffed and supported to implement and maintain BCD domain capabilities.
▪ Technology is leveraged to enhance the efficiency and accuracy of BC/DR operations (e.g., BC/DR planning software, Disaster Recovery as a Service (DRaaS), Orchestration and Automation Tools).
▪ The entity's Governance, Risk & Compliance (GRC) team, or similar function, works with business stakeholders and process owners to appropriately scope and reasonably implement cybersecurity and data protection controls associated with BCD domain capabilities to address Minimum Compliance Requirements (MCR) (e.g., applicable statutory, regulatory and/or contractual requirements) and Discretionary Security Requirements (DSR) (e.g., entity-required controls).
Level 4 Quantitatively Controlled
Utilize SCR-CMM Level 3 criteria definitions:
▪ There are no defined Level 4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to operationalize this control.
▪ While it may be possible to develop “metrics-driven” capabilities for this control, the criteria would be organization-specific to define.
Level 5 Continuously Improving
Utilize SCR-CMM Level 3 or Level 4 (if available) criteria definitions:
▪ There are no defined Level 5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to operationalize this control.
▪ Level 5 capabilities should be considered “world-class” where the control builds on Level 4 capabilities, but are continuously improving through Artificial Intelligence (AI) and/or Machine Learning (ML) technologies.
▪ While it may be possible to develop responsive capabilities for this control through the use of AI and/or ML technologies, the criteria would be organization-specific to define.
1. Áttekintés
1.1 Hivatkozások
1.2 Azonosított követelmények
1.3 Kapcsolódó szabályozások
2. Azonosított követelmények
Követelmények
| Forrás |
Követelmény |
3. Kapcsolódó szabályozások
Szabályozások
| Forrás |
Szabályozás |
|
EULAW
|
11. cikk (1)
A 6. cikk (1) bekezdésében említett IKT-kockázatkezelési keretrendszer részeként, a 8. cikkben említett azonosítási követelmények alapján a pénzügyi szervezeteknek átfogó IKT-üzletmenetfolytonossági politikát kell bevezetniük, amelyet a pénzügyi szervezet átfogó üzletmenet-folytonossági politikájának integráns részét képező célzott egyedi szabályzatként is elfogadhatnak.
|
|
EULAW
|
11. cikk (2)
A pénzügyi szervezeteknek az IKT-üzletmenetfolytonossági politikát célzott, megfelelő és dokumentált intézkedések, tervek, eljárások és mechanizmusok útján kell végrehajtaniuk, a következők céljából:
a)
a folytonosság biztosítása a pénzügyi szervezet kritikus vagy fontos funkcióinak ellátásában;
b)
valamennyi IKT-vonatkozású incidensre gyors, megfelelő és eredményes reagálás és annak megoldása a kár mérséklésével, a tevékenység újraindítását és a helyreállítási intézkedéseket előtérbe helyezve;
c)
célzott tervek haladéktalan aktiválása, amelyek lehetővé teszik az IKT-vonatkozású incidensek egyes típusainak megfelelő, elszigetelésre irányuló intézkedések, folyamatok és technológiák alkalmazását, a további károk megelőzését, valamint a 12. cikkel összhangban kialakított célzott reagálási és helyreállítási intézkedéseket;
d)
előzetes hatások, károk és veszteségek felmérése;
e)
olyan kommunikációs és válságkezelési intézkedések meghatározása, amelyek biztosítják a naprakész információk eljuttatását a releváns belső személyzet valamennyi tagja és valamennyi külső érdekelt fél részére a 14. cikk, valamint az illetékes hatóságok részére a 19. cikk szerint.
|
|
EULAW
|
11. cikk (3)
A 6. cikk (1) bekezdésében említett IKT-kockázatkezelési keretrendszer részeként a pénzügyi szervezeteknek kapcsolódó IKT-vonatkozású reagálási és helyreállítási terveket kell bevezetniük, amelyeket a mikrovállalkozásnak nem minősülő pénzügyi szervezetek esetében független belső felülvizsgálatnak kell alávetni.
|
|
EULAW
|
11. cikk (4)
A pénzügyi szervezeteknek – különösen a harmadik fél IKT-szolgáltatókkal kötött megállapodások keretében kiszervezett vagy megbízásba adott kritikus vagy lényeges funkciókra vonatkozóan – megfelelő IKT-üzletmenetfolytonossági terveket kell bevezetniük és fenntartaniuk, amelyeket időszakonként tesztelniük kell.
|
|
EULAW
|
11. cikk (5)
Az átfogó üzletmenet-folytonossági politika részeként a pénzügyi szervezeteknek üzleti hatáselemzést (BIA) kell végezniük az üzletmenetben okozott súlyos zavaroknak való kitettségükről. Az üzleti hatáselemzés keretében a pénzügyi szervezeteknek mennyiségi és minőségi kritériumok alapján értékelniük kell az üzletmenetben okozott súlyos zavarok lehetséges hatását, adott esetben belső és külső adatok és forgatókönyv-elemzés felhasználásával. Az üzleti hatáselemzésnek tekintetbe kell vennie az azonosított és felvázolt üzleti funkcióknak, támogatási folyamatoknak, harmadik felektől való függőségeknek és információs vagyonelemeknek, valamint azok kölcsönös függőségeinek a kritikusságát. A pénzügyi szervezeteknek biztosítaniuk kell, hogy az IKT-eszközöket és IKT-szolgáltatásokat az üzleti hatáselemzéssel teljes összhangban alakítsák ki és használják, különösen valamennyi kritikus összetevő redundanciájának megfelelő biztosítása tekintetében.
|
|
EULAW
|
11. cikk (6)
Átfogó IKT-kockázatkezelésük keretében a pénzügyi szervezeteknek:
a)
tesztelniük kell az IKT-üzletmenetfolytonossági terveket és az IKT-reagálási és -helyreállítási terveket a valamennyi funkciót támogató IKT-rendszerekhez kapcsolódóan legalább évente, valamint a kritikus vagy fontos funkciókat támogató IKT-rendszereket érintő bármely jelentős változás bekövetkezése esetén;
b)
tesztelniük kell a 14. cikknek megfelelően kialakított válsághelyzeti kommunikációs terveket.
Az első albekezdés a) pontjának alkalmazásában a mikrovállalkozásnak nem minősülő pénzügyi szervezeteknek a tesztelési terveikben szerepeltetniük kell a kibertámadásokra, továbbá az elsődleges IKT-infrastruktúrájuk és a 12. cikkben meghatározott kötelezettségek teljesítéséhez szükséges tartalékkapacitás, biztonsági mentések és tartalékeszközök közötti átállásokra vonatkozó forgatókönyveket. A pénzügyi szervezeteknek rendszeresen felül kell vizsgálniuk az IKT-üzletmenetfolytonossági politikájukat, valamint az IKT-reagálási és -helyreállítási terveiket, figyelembe véve az első albekezdés szerint elvégzett tesztek eredményeit, valamint az ellenőrzések és felügyeleti felülvizsgálatok alapján megfogalmazott ajánlásokat.
|
|
EULAW
|
11. cikk (7)
A mikrovállalkozásnak nem minősülő pénzügyi szervezeteknek olyan válságkezelési funkcióval kell rendelkezniük, amely az IKT-üzletmenet-folytonossági terveik vagy az IKT-reagálási és helyreállítási terveik aktiválása esetén a 14. cikkel összhangban többek között egyértelmű eljárásokat határoz meg a belső és külső válsághelyzeti kommunikáció kezelésére vonatkozóan.
|
|
EULAW
|
11. cikk (8)
A pénzügyi szervezeteknek az olyan, zavart okozó eseményeket megelőzően és azok időtartama alatt végzett tevékenységekről, amikor az IKT-üzletmenetfolytonossági terveik és az IKT-reagálási és -helyreállítási terveik aktiválására kerül sor, könnyen hozzáférhető nyilvántartást kell vezetniük.
|
|
EULAW
|
11. cikk (9)
A központi értéktáraknak az illetékes hatóságok rendelkezésére kell bocsátaniuk az IKT-vonatkozású üzletmenet- folytonossági tesztek vagy hasonló műveletek eredményeinek másolatát.
|
|
EULAW
|
11. cikk (10)
A mikrovállalkozásnak nem minősülő pénzügyi szervezeteknek az illetékes hatóságok kérésére jelentést kell tenniük a jelentős IKT-vonatkozású incidensek által okozott költségek és veszteségek összesített éves becsléséről.
|
|
EULAW
|
11. cikk (11)
Az 1093/2010/EU rendelet, az 1094/2010/EU rendelet és az 1095/2010/EU rendelet 16. cikkével összhangban az EFH-knak a vegyes bizottság keretében 2024. július 17-ig közös iránymutatásokat kell kidolgozniuk a (10) bekezdésben említett költségek és veszteségek összesített éves becslésére vonatkozóan.
|
|
EULAW
|
12. cikk (1)
Annak biztosítása céljából, hogy IKT-rendszereiket és adataikat minimális leállási időt, valamint korlátozott mértékű zavart és veszteséget követően állíthassák helyre, a pénzügyi szervezeteknek – IKT-kockázatkezelési keretrendszerük részeként – ki kell dolgozniuk és dokumentálniuk kell a következőket:
a)
olyan biztonsági mentési szabályzatok és eljárások, amelyek az információk kritikussága vagy az adatok bizalmassági szintje alapján meghatározzák a biztonsági mentéssel érintett adatok körét és a biztonsági mentés minimális gyakoriságát;
b)
visszaállítási és helyreállítási eljárások és módszerek.
|
|
EULAW
|
32. cikk Az adatkezelés biztonsága
|
|
EULAW
|
21. cikk A kiberbiztonsági kockázatkezelési intézkedések
|
|
EULAW
|
24. cikk Az IKT-üzletmenet-folytonossági politika elemei
|
|
EULAW
|
5. cikk Irányítás és szervezés
|
|
EULAW
|
11. cikk Reagálás és helyreállítás
|
|
EULAW
|
16. cikk Egyszerűsített IKT-kockázatkezelési keretrendszer
|
|
EULAW
|
5. cikk (2)
A pénzügyi szervezet vezető testületének kell meghatároznia, jóváhagynia és felvigyáznia a 6. cikk (1) bekezdésében említett IKT-kockázatkezelési keretrendszerrel összefüggő valamennyi intézkedést, és viselnie a felelősséget azok végrehajtásáért. Az első albekezdés alkalmazásában a vezető testület:
a)
viseli a végső felelősséget a pénzügyi szervezet IKT-kockázatainak kezeléséért;
b)
bevezet az adatok rendelkezésre állására, hitelességére, integritására és bizalmas kezelésére vonatkozó magas szintű normák fenntartását biztosítani célzó politikákat;
c)
egyértelmű feladat- és felelősségi köröket jelöl ki valamennyi IKT-vonatkozású funkcióval összefüggésben, és létrehozza az említett funkciók közötti hatékony és jól időzített kommunikációt, együttműködést és koordinációt biztosító, megfelelő irányítási rendszert;
d)
viseli a 6. cikk (8) bekezdésében említett, digitális működési rezilienciára vonatkozó stratégia létrehozásával és jóváhagyásával kapcsolatos általános felelősséget, ideértve a pénzügyi szervezet megfelelő IKT-kockázati toleranciaszintjének a 6. cikk (8) bekezdésének b) pontjában említett megállapítását is;
e)
jóváhagyja, felvigyázza és időszakonként felülvizsgálja a pénzügyi szervezetnek a 11. cikk (1), illetve (3) bekezdésében említett IKT-üzletmenetfolytonossági politikáját, illetve IKT-reagálási és -helyreállítási tervét, amelyeknek elfogadására sor kerülhet a pénzügyi szervezet átfogó üzletmenet-folytonossági politikájának, valamint reagálási és helyreállítási tervének integráns részét képező célzott egyedi szabályzat formájában is;
f)
jóváhagyja és időszakonként felülvizsgálja a pénzügyi szervezet IKT-vonatkozású belső ellenőrzési terveit, IKT-ellenőrzéseit és azok lényeges módosításait;
g)
megállapítja és időszakonként felülvizsgálja a pénzügyi szervezet digitális működési rezilienciával kapcsolatos szükségleteinek kielégítését biztosító költségvetést minden erőforrástípus tekintetében, ideértve a személyzet valamennyi tagja számára biztosítandó, a 13. cikk (6) bekezdésében említett releváns, IKT-biztonsági tudatosságot elősegítő programokat és digitális működési rezilienciával kapcsolatos képzéseket, valamint IKT-készségeket;
h)
jóváhagyja és időszakonként felülvizsgálja a pénzügyi szervezetnek a harmadik fél IKT-szolgáltatók által nyújtott IKT-szolgáltatások igénybevételéről szóló megállapodásokkal kapcsolatos szabályait;
i)
vállalati szinten létrehozza a következőkkel kapcsolatos megfelelő tájékozódást lehetővé tevő bejelentési csatornákat:
i.
a harmadik fél IKT-szolgáltatókkal az IKT-szolgáltatások igénybevételére vonatkozóan kötött megállapodások;
ii.
bármely releváns, a harmadik fél IKT-szolgáltatókra vonatkozó tervezett lényeges változtatás;
iii.
az ilyen változtatások potenciális hatása az említett megállapodásokkal érintett kritikus vagy fontos funkciókra, ideértve az említett változtatások hatását értékelő kockázatelemzés-összefoglalót, továbbá legalább a jelentős IKT-vonatkozású incidensek és azok hatásai, valamint reagálási, helyreállítási és korrekciós intézkedések.
|
|
EULAW
|
16. cikk (1)
E rendelet 5–15. cikke nem alkalmazandó a következőkre: az (EU) 2015/2366 irányelv alapján mentesített kis méretű és össze nem kapcsolt befektetési vállalkozások, pénzforgalmi intézmények; a 2013/36/EU irányelv alapján mentesített azon intézmények, amelyek tekintetében a tagállamok úgy döntöttek, hogy nem alkalmazzák az e rendelet 2. cikkének (4) bekezdésében említett opciót; a 2009/110/EK irányelv alapján mentesített elektronikuspénz-kibocsátó intézmények; és a kis méretű foglalkoztatói nyugellátást szolgáltató intézmények. Az első albekezdés sérelme nélkül az első albekezdésben felsorolt szervezeteknek:
a)
megbízható és dokumentált IKT-kockázatkezelési keretrendszert kell létrehozniuk és fenntartaniuk, amely részletezi az IKT-kockázat gyors, hatékony és átfogó kezelését célzó mechanizmusokat és intézkedéseket, többek között a releváns fizikai összetevők és infrastruktúrák védelme érdekében;
b)
folyamatosan nyomon kell követniük valamennyi IKT-rendszer biztonságát és működését;
c)
minimalizálniuk kell az IKT-kockázat hatását olyan megbízható, reziliens és naprakész IKT-rendszerek, -protokollok és -eszközök alkalmazásával, amelyek alkalmasak tevékenységeik végzésének és a szolgáltatások nyújtásának támogatására, valamint a hálózati és információs rendszerekben tárolt adatok rendelkezésre állásának, hitelességének, integritásának és bizalmas jellegének megfelelő fenntartására;
d)
lehetővé kell tenniük a hálózati és információs rendszerekben jelentkező IKT-kockázat és -rendellenességek forrásainak azonnali azonosítását és felderítését, valamint az IKT-vonatkozású incidensek gyors kezelését;
e)
azonosítaniuk kell a harmadik fél IKT-szolgáltatóktól való főbb függőségeket;
f)
biztosítaniuk kell a kritikus vagy lényeges funkciók folytonosságát olyan üzletmenet-folytonossági tervek, valamint reagálási és helyreállítási intézkedések révén, amelyek magukban foglalják legalább a biztonsági mentést és helyreállítást biztosító intézkedéseket;
g)
rendszeresen tesztelniük kell az f) pontban említett terveket és intézkedéseket, valamint az a) és c) pontnak megfelelően végrehajtott kontrollok hatékonyságát;
h)
adott esetben be kell építeniük az IKT-kockázatértékelési folyamatba a g) pontban említett tesztekből és az incidensek utólagos elemzéséből származó releváns operatív következtetéseket, és az igényeknek és az IKT-kockázati profilnak megfelelően IKT-biztonsági tudatosságnövelő programokat és digitális működési reziliencia-képzéseket kell kidolgozniuk a személyzet és a vezetés számára.
|
Kapcsolt feladatok
- Secure Controls Framework -
"The SCF is the Common Controls Framework™ (CCF), the world's most comprehensive cybersecurity and data privacy metaframework - it is also free to use. The entire concept is building secure, compliant and resilient capabilities in the most efficient and cost-effective manner possible.
The SCF is more than just a unified control catalog, since its included content creates a playbook for Governance, Risk & Compliance (GRC) capabilities. Used globally by organizations of every size, the SCF is a robust and scalable solution for security, compliance and resilience controls. As a comprehensive security framework, the SCF maps 1,400+ controls across 200+ laws, regulations, and industry frameworks so you can implement once and comply everywhere.
Like it or not, cybersecurity is a protracted war on an asymmetric battlefield, where the threats are everywhere and as defenders we have to make the effort to work together to help improve cybersecurity and data privacy practices, since we all suffer when massive data breaches occur or when cyber attacks have physical impacts. Hackers share information on attack methods with other hackers, so why shouldn’t the good guys share information on how to best protect an organization? We decided to take action and make a difference, since we feel it is too important to wait for someone else to fix the problems that exist.
The SCF is made up of volunteers, mainly specialists within the cybersecurity profession, who focus on GRC and the cybersecurity side of data privacy. These are auditors, engineers, architects, incident responders, consultants and other specialists who live and breathe these topics on a daily basis. The end product is "expert-derived content" that makes up the SCF." https://securecontrolsframework.com/
Terms & Conditions
The SCF End User License Agreement (EULA) governs the use of the Secure Controls Framework® (SCF) under the Creative Commons Attribution-No Derivatives 4.0 International Public License.
|