정보관리기술사 학습 노트
← 목록으로
보안·개인정보
#DORA#디지털 운영 복원력#ICT 위험관리#금융 보안#제3자 위험#CTPP#Regulation (EU) 2022/2554
최종 업데이트 · 2026-09-29

EU DORA 기반 금융 디지털 운영 복원력 관리

1. 개요

가. 정의와 등장 배경

디지털 운영 복원력법(Digital Operational Resilience Act, DORA)은 금융회사가 ICT 위험을 통합적으로 관리하고, 장애·사이버공격에 대비해 서비스를 지속·복구하며, ICT 제3자 의존성을 통제하도록 요구하는 유럽연합의 금융 부문 규정(Regulation (EU) 2022/2554)이다.

금융서비스는 결제, 거래, 신용, 보험금 지급, 시장 인프라가 상호 연결되어 있어 한 사업자의 ICT 장애가 다수 기관과 고객에게 전파될 수 있다. 클라우드·데이터센터·핵심 소프트웨어 공급자에 대한 의존이 커지면서 개별 금융회사의 보안 통제만으로는 생태계 차원의 집중 위험과 연쇄 장애를 충분히 다루기 어렵다. DORA는 이런 문제를 보안 사고 대응에서 디지털 운영 복원력의 전 생애주기 관리로 확장한다.

DORA는 2022년 제정된 Regulation (EU) 2022/2554이며 2025년 1월 17일부터 적용된다. 규정은 ICT 위험관리, 중대 ICT 사고 보고, 디지털 운영 복원력 테스트, ICT 제3자 위험관리, 위협정보 공유라는 상호 보완적 영역을 묶는다. 기술사는 이를 법무 체크리스트로 한정하지 않고 업무서비스·자산·공급자·복구 목표·증적을 연결하는 운영 아키텍처로 해석해야 한다.

나. 목표와 적용 관점

DORA의 복원력은 장애가 발생하지 않는 상태만을 뜻하지 않는다. 예방이 실패하더라도 탐지·대응·복구가 가능하고, 고객에게 미치는 영향을 허용 가능한 수준으로 제한하며, 사후 학습으로 통제를 개선하는 역량을 뜻한다. 따라서 정보보호 관리체계, 업무연속성, IT 서비스 관리, 조달·위탁 관리가 따로 움직이지 않고 동일한 중요 업무서비스를 기준으로 정렬되어야 한다.

적용 범위에는 은행, 결제·전자화폐 기관, 투자회사, 보험사, 시장 인프라 등 폭넓은 금융기관이 포함되며, 각 기관 유형과 예외는 규정 제2조를 기준으로 판단해야 한다. ICT 서비스 공급자가 금융기관을 지원한다는 사실만으로 모두 동일한 직접 의무를 지는 것은 아니다. 금융기관은 공급자 위험을 관리해야 하며, 별도로 유럽감독당국(ESA)이 중요하다고 지정한 핵심 ICT 제3자 공급자(CTPP)는 EU 차원의 감독 프레임워크 대상이 된다.

유럽 외 조직도 EU 금융기관에 서비스를 공급하거나 금융기관의 외부 ICT 서비스망에 포함되는 경우 계약·위험관리·감사·하위위탁 조건의 영향을 받을 수 있다. 한국 기업은 직접 적용 여부와 별개로 고객사의 계약상 보안 요건, 정보제공 요청, 사고 통지, 복구 증거 제출에 대비할 필요가 있다. 역외 사업자의 법적 지위와 세부 의무는 계약 당사자 및 규정 적용 조건에 따라 달라지므로, 법률 검토와 관할 감독기관의 안내를 함께 확인한다.

2. DORA 참조 구조와 복원력 관리 체계

DORA 이행은 규정 조항을 조직 내 담당 부서에 단순 배분하는 것보다, 중요 업무서비스에서 기술 자산과 공급자까지 이어지는 의존성 지도를 만드는 데서 시작한다. 업무 영향 분석은 서비스의 중단 허용 시간, 데이터 손실 허용량, 고객·시장 영향과 복구 우선순위를 산출한다. 이 기준을 ICT 자산 목록, 위험 시나리오, 통제, 테스트, 사고 보고 및 복구 계획에 연결하면 각 통제가 어떤 업무 결과를 보호하는지 설명할 수 있다.

flowchart TB
  A["중요 업무서비스·업무영향 분석"] --> B["ICT 자산·데이터·공급자 의존성"]
  B --> C["ICT 위험관리 프레임워크"]
  C --> D["보호·탐지·대응·복구 통제"]
  D --> E["사고 분류·보고·고객 소통"]
  D --> F["복원력 테스트·개선"]
  B --> G["제3자 위험·계약·하위위탁 관리"]
  E --> H["경영진 검토·시정조치"]
  F --> H
  G --> H
  H --> C

가. ICT 위험관리와 거버넌스

금융기관은 ICT 위험을 전사 위험관리의 일부로 다루고, 책임·정책·역할·보고 경로를 명확히 해야 한다. 이사회와 경영진의 책임은 기술 부서에 위임해 사라지는 것이 아니며, 위험 선호와 중요 업무서비스의 복원력 목표를 승인하고 이행 상태를 감독해야 한다. 실무에서는 서비스 소유자, 정보보호 책임자, ICT 운영, 위험관리, 업무연속성, 조달 및 내부감사가 공통 용어와 증적 체계를 사용하도록 한다.

위험관리 프레임워크는 업무 기능과 이를 지원하는 정보·ICT 자산을 식별하고, 위협·취약점·영향을 평가한 뒤 보호·탐지·대응·복구 통제를 선택하는 반복 과정이다. 자산 목록은 서버와 네트워크에 그치지 않고 데이터 흐름, 계정·인증, 소프트웨어 구성요소, 클라우드 리전, 외주 운영, 백업 복구 경로까지 포함해야 한다. 구성 변경과 조직 인수·합병, 공급자 교체가 일어나면 의존성 지도와 위험평가를 다시 검토한다.

통제는 기밀성·무결성·가용성에 더해 서비스의 복구 가능성과 의사결정 속도를 다뤄야 한다. 다중 리전 구성은 한 리전 장애에 도움이 되지만 동일한 자격증명, 제어 평면, 데이터 손상에 함께 노출되면 독립된 복구 수단이 아니다. 따라서 위험 시나리오별로 예방 통제, 탐지 신호, 격리 절차, 대체 운영, 복구 검증의 연결성을 확인한다.

나. 사고 관리와 보고

사고 대응은 기술 경보를 업무 영향과 결합하는 데서 출발한다. 같은 서버 오류라도 내부 개발 환경의 단기 지연과 결제·거래 기능의 장시간 중단은 중대성, 보고 경로, 고객 영향이 다르다. 기관은 분류 기준과 책임자를 정하고, 사건이 일정 임계값을 넘는 경우 상위 대응 조직과 경영진에 신속하게 승격해야 한다.

DORA 체계에서는 중대 ICT 관련 사고와 주요 사이버 위협의 처리·보고를 표준화한다. 분류는 영향받은 고객·거래·서비스, 지속 시간, 지리적 확산, 데이터 손상, 경제적 영향 등 규정과 기술기준의 기준을 반영해야 한다. 최초 통지, 중간 보고, 최종 보고를 위한 사실관계·타임라인·원인·대응조치·복구 상태를 기록하되, 초기에 불확실한 정보를 확정 사실처럼 보고하지 않는다.

사고 대응에는 보안관제, 서비스데스크, 업무 책임자, 법무·준법, 개인정보 담당, 공급자와 감독기관 연락망이 참여한다. 공급자 계약에 사고 통지 기한, 로그·증적 보존, 조사 협조, 하위 공급자 통지, 복구 지원을 포함해야 보고 의무를 현실적으로 수행할 수 있다. 사고 종료 뒤에는 원인 분석과 시정조치의 책임자·기한을 정하고, 유사 서비스와 공급자에도 교훈을 적용한다.

다. 디지털 운영 복원력 테스트

테스트는 정책의 존재 여부가 아니라 통제가 실제 업무 조건에서 작동하는지를 검증한다. 기본 점검과 취약점 분석부터 시나리오 기반 테스트, 복구훈련, 독립 검토에 이르기까지 테스트 강도는 서비스 중요도와 위험에 비례해 설계한다. 테스트 환경은 운영을 무분별하게 손상시키지 않으면서도 운영과 동일한 주요 의존성·권한·데이터 경로를 반영해야 한다.

테스트 범위에는 ICT 시스템과 애플리케이션, 인프라, 데이터센터, 네트워크, 인력 및 제3자 서비스 등 중요 자산이 포함될 수 있다. 복구훈련은 백업이 생성되었는지만 확인하지 말고, 깨끗한 환경에서 복원 가능한지, 데이터 정합성이 유지되는지, 업무 담당자가 실제 전환을 승인할 수 있는지 확인한다. 테스트 결과는 발견사항의 심각도, 업무 영향, 보완 책임자, 재시험 기준과 함께 기록한다.

위협주도 침투시험(TLPT)은 실제 위협정보를 바탕으로 핵심 기능에 대한 고급 공격을 모의하는 고강도 테스트다. 모든 금융기관에 같은 주기로 무조건 수행하는 일반 취약점 점검과 구분되며, 규정상 지정된 금융기관이 관할 당국의 감독 아래 수행한다. 시험의 범위·위험 통제·외부 시험자 독립성·공급자 참여·결과 공유는 관련 규정과 기술기준, 관할 감독당국의 지침에 맞춰야 한다.

라. ICT 제3자 위험관리와 CTPP 감독

외부 위탁은 위험의 이전이 아니라 위험 노출의 확장이다. 금융기관은 계약 전 실사, 중요성·집중도 평가, 계약 체결, 지속 모니터링, 종료·전환까지 ICT 서비스의 전체 수명주기를 관리한다. 특히 중요 업무 기능을 뒷받침하는 서비스는 공급자 변경 가능성, 데이터 이동성, 하위위탁, 관할권, 감사권, 복구 의존성을 사전에 분석해야 한다.

기관은 ICT 제3자 계약 정보를 등록부(register of information)에 체계적으로 기록하고, 조직·그룹 수준에서 서비스·공급자·하위위탁 관계를 추적해야 한다. 등록부는 단순 조달 목록이 아니라 공급자 집중 위험, 중요 기능 의존성, 대체 가능성 및 감독 보고를 분석하는 데이터 기반이다. 정보가 조직마다 다른 형식으로 저장되면 감독 보고와 영향 분석이 지연되므로, 서비스 식별자와 공급자 마스터를 일관되게 관리한다.

핵심 ICT 제3자 공급자(CTPP)의 지정과 감독은 금융기관별 공급자 위험관리와 구별되는 EU 차원의 감독 기능이다. ESA는 규정과 지정 기준에 따라 금융 부문 전체의 중요도와 상호연결성 등을 평가하고, 지정된 공급자에 대해 주감독자(Lead Overseer)가 감독 활동을 조정한다. 그렇다고 금융기관의 개별 공급자 관리 책임이 감독당국으로 이전되는 것은 아니며, 기관은 자신의 위험평가·계약·통제·복구 책임을 계속 수행한다.

3. 구현 아키텍처와 운영 절차

실행 가능한 이행 모델은 거버넌스와 기술 데이터 흐름을 함께 설계한다. 서비스 카탈로그, CMDB, 데이터 계보, 계약 저장소, 위험관리 도구, ITSM, SIEM, 복구 플랫폼이 서로 다른 식별자를 사용하면 사고나 테스트 결과를 중요 업무서비스에 연결하기 어렵다. 공통 서비스 ID, 공급자 ID, 자산 ID와 책임자 정보를 기준으로 증적을 연결하는 것이 자동화의 전제다.

sequenceDiagram
  participant BUS as 업무서비스 소유자
  participant GRC as 위험·규제 관리
  participant IT as ICT 운영·보안
  participant V as 공급자 관리
  participant TEST as 테스트·복구 조직
  BUS->>GRC: 중요 서비스·영향 허용치 등록
  GRC->>IT: 통제·위험 시나리오 배정
  GRC->>V: 공급자·계약·등록부 요구
  IT->>TEST: 복구·사고 시나리오와 범위 전달
  TEST-->>GRC: 결과·결함·재시험 증적
  IT-->>BUS: 서비스 상태·복구 영향 보고
  V-->>GRC: 공급자 변경·사고·하위위탁 통지
  GRC-->>BUS: 잔여 위험·시정조치·승인 요청

가. 업무서비스 중심의 데이터 모델

기술 자산 목록만으로는 규정 준수와 복원력 수준을 판단하기 어렵다. 서비스-업무기능-데이터-애플리케이션-인프라-공급자 간 의존성 그래프를 구성해야 특정 클라우드 리전이나 인증서비스의 장애가 어떤 고객 업무에 영향을 주는지 분석할 수 있다. 그래프에는 소유자, 중요도, 복구목표, 데이터 등급, 공급자, 계약, 테스트 결과와 마지막 검토 시점을 연결한다.

예를 들어 해외송금 서비스가 고객채널, 인증, 사기탐지, 결제망 연결, 클라우드 데이터베이스와 외부 메시징에 의존한다면, 각 구성요소의 기술적 복구만으로 전체 서비스 복구를 보장할 수 없다. 서비스의 순서 의존성, 수동 우회 가능성, 규제상 제한, 고객 공지를 고려해 업무 단위 복구 시나리오를 설계한다. 업무 영향 분석이 변경되면 기술 복구 순위와 공급자 계약의 중요성 판단도 함께 갱신한다.

나. 증적 자동화와 변경관리

정책·위험평가·자산 목록·사고기록·테스트 결과·공급자 계약을 증적 카탈로그에 연결하면 감독 질의에 대한 응답과 내부 감사의 재현성이 높아진다. 자동 수집은 구성 변경, 취약점 상태, 백업 성공, 테스트 완료, 공급자 상태와 같은 관측 가능한 사실에 유용하다. 그러나 자동화된 점수만으로 잔여 위험을 승인하지 말고, 업무 영향과 예외 사유를 책임자가 검토해야 한다.

변경관리에는 업무서비스 영향 분석, 보안·복구 통제 확인, 공급자 통지, 문서 갱신, 테스트와 승인 절차를 포함한다. 예를 들어 데이터베이스를 다른 리전이나 공급자로 이전할 때는 연결 구성 변경뿐 아니라 데이터 이전 검증, 암호키 관리, 백업 복원, 지연시간, 계약상 국외 이전 조건을 재평가한다. 중요한 변경을 배포 승인 단계에서 복원력 테스트나 위험 검토와 연계하면 규정 문서와 실제 운영의 괴리를 줄일 수 있다.

다. 서비스 복구와 위기 의사결정

복구 목표는 기술팀이 임의로 정하는 서버 단위 시간값이 아니라 업무 영향과 위험 선호에서 도출한다. 복구시간목표(RTO)와 복구시점목표(RPO)는 서비스 상호 의존성, 데이터 재생 가능성, 고객·시장 손실과 운영비용을 반영해 승인한다. 기술 복구가 완료되어도 업무 데이터 정합성, 거래 재처리, 고객 통지와 대사까지 끝나야 서비스 복원으로 판단할 수 있다.

위기 시에는 권한 있는 지휘자가 격리, 대체 운영, 공급자 에스컬레이션, 데이터 복구와 고객 공지의 우선순위를 결정한다. 자동화는 탐지와 반복 작업을 빠르게 할 수 있지만, 거래 중단이나 데이터 롤백처럼 되돌리기 어려운 조치는 승인과 안전장치를 둔다. 복구훈련에서 의사결정의 지연과 승인 충돌도 측정해야 기술적 복구시간만 줄이는 최적화에 그치지 않는다.

4. 유사 체계와의 비교

DORA는 사이버보안·업무연속성·아웃소싱 통제와 겹치는 영역이 있지만, 금융 부문의 디지털 복원력을 하나의 직접 적용 가능한 규정으로 정렬한다는 점에서 독자성이 있다. 국제표준이나 일반 보안 프레임워크를 갖추었다고 해서 DORA 의무가 자동 충족되는 것은 아니다. 반대로 기존 통제와 증적을 DORA 요구사항에 매핑하면 중복을 줄이고, 규정만을 위한 별도 운영조직을 만드는 위험을 낮출 수 있다.

비교축 DORA ISO/IEC 27001 전통적 BCP·DR
주된 목적 금융 부문의 ICT 운영 복원력 정보보호 관리체계의 지속적 개선 업무 중단 시 연속·복구
규범 성격 EU 법규 및 관련 기술기준 자발적 국제표준·인증체계 조직 정책·표준·계약에 따라 다름
핵심 범위 위험, 사고보고, 테스트, 제3자, 정보공유 정보보호 위험과 통제 업무 영향, 대체 운영, 복구 절차
책임 초점 금융기관 경영진과 기관별 의무 조직의 경영시스템과 통제 소유자 업무·IT 복구 책임자
실무적 관계 공통 증적·위험관리 위에 규제 의무 추가 보안 통제의 기반으로 재사용 가능 복구 역량과 훈련을 연결

이 차이는 어느 체계가 더 우월하다는 뜻이 아니다. ISO/IEC 27001은 정보보호 관리의 체계적 운영에 강점이 있고, BCP·DR은 업무 중단 시 연속성 계획에 초점을 둔다. DORA는 사고 보고, 복원력 테스트와 금융기관-ICT 공급자 관계를 감독 가능한 의무로 연결하므로, 기존 체계를 DORA 기준에 매핑해 빈틈을 찾는 방식이 합리적이다.

가. 산업 적용 사례

가상의 유럽계 은행이 핵심 클라우드 리전 장애로 모바일 결제와 자금이체를 처리할 수 없다고 가정한다. 서비스 의존성 그래프를 통해 인증, 거래 원장, 사기탐지, 통지 채널의 대체 경로를 확인하고, 영향 허용치에 따라 우회·제한 운영·복구 순서를 선택한다. 사고팀은 시간대별 영향·거래 건수·데이터 정합성·고객 공지를 기록하며, 공급자는 조사·로그·복구 협조를 계약에 따라 제공한다.

두 번째 사례는 핵심 SaaS 공급자의 하위위탁 구조가 변경되는 상황이다. 기관은 공급자 등록부와 중요 업무 의존성에서 영향받는 기능을 찾고, 데이터 처리 위치·하위 공급자·감사권·전환 지원을 재검토한다. 즉각적인 대체가 불가능하면 보완 통제와 출구 전략을 마련하고, 변경을 승인할 잔여 위험 소유자를 지정한다.

세 번째 사례는 백업은 매일 성공하지만 복구 테스트에서 키 관리 서비스가 같은 장애 도메인에 묶여 복호화하지 못하는 상황이다. 백업 성공 지표만으로는 복원력을 입증할 수 없으며, 독립 자격증명·키 복구 절차·데이터 무결성 확인을 포함한 복구훈련이 필요하다. 테스트 발견사항을 조달 조건과 아키텍처 표준에 반영하면 같은 취약성이 다른 업무 서비스에서 반복되는 것을 줄일 수 있다.

5. 심화: DORA 적용 이후의 감독과 운영 성숙도

DORA는 2025년 1월 17일부터 적용되었으며, 전 금융기관이 같은 규모의 통제와 테스트를 수행해야 한다는 뜻은 아니다. 비례성 원칙을 고려하되 중요 업무, 규모, 위험 프로필, 서비스 복잡성에 맞춰 통제 강도를 설명 가능하게 조정해야 한다. 조직이 작은 경우에도 중요 서비스의 자산·공급자·사고·복구 통제와 책임을 명확히 해야 하며, 간소화가 핵심 위험을 무시하는 면책으로 오해되어서는 안 된다.

제3자 감독에서는 금융기관의 계약상 위험관리와 ESA의 CTPP 직접 감독을 구분하는 것이 중요하다. ESA의 중요 공급자 감독은 금융 생태계의 집중 위험을 다루지만, 각 금융기관은 자체 위험 평가와 공급자 선정, 계약 통제, 업무 연속성 및 출구 계획을 계속 책임진다. 2026년 현재 ESMA의 DORA 감독 안내는 지정 절차, 주감독자 역할과 감독 프레임워크 관련 공식 자료를 제공하므로 최신 지정·감독 상태는 해당 안내와 관할기관 공지에서 확인한다.

감독 대응은 감사 직전에 문서를 모으는 방식보다 통제의 실행 증거를 지속 수집하는 방식으로 발전해야 한다. 예를 들어 변경 승인, 복구훈련, 사고 타임라인, 공급자 등록부 갱신의 기록이 공통 서비스 식별자로 연결되면 규제 보고와 경영진의 위험 판단을 함께 지원한다. 다만 수집 가능한 모든 정보를 보관하는 것이 목적은 아니며, 개인정보 최소화·보존정책·접근통제를 증적 설계에 적용해야 한다.

6. 고려사항 및 시사점

가. 규정 준수와 서비스 회복력의 결합

문서·정책 수립만으로 운영 복원력이 향상되지는 않는다. 실제 중요 업무서비스의 장애 시나리오를 기준으로 복구훈련과 통제 검증을 수행하고, 확인된 약점을 예산·인력·아키텍처 개선으로 연결한다.

나. 비례성과 일관성

기관의 규모와 서비스 복잡성에 맞춘 비례성은 필요하지만, 중요 서비스 정의와 위험 수용 기준을 조직마다 임의로 다르게 적용하면 그룹 차원의 감독과 비교가 어려워진다. 최소 공통 분류체계와 통제 원칙을 두고, 개별 기관의 추가 위험을 확장 관리하는 계층형 모델이 바람직하다.

다. 공급자 집중과 출구 전략

다중 공급자 도입이 항상 위험을 줄이는 것은 아니다. 동일한 인증, DNS, 네트워크 연결, 관리 콘솔과 하위위탁에 의존하면 복수 공급자도 공통 장애점에 노출된다. 대체 가능성은 데이터 이동·업무 재구축·계약 종료·인력 전환까지 포함해 시험하고, 비현실적인 출구 계획을 정기적으로 수정한다.

라. 테스트 안전성과 독립성

침투시험과 복구훈련은 운영 장애를 유발하거나 고객 데이터를 노출하지 않도록 범위·권한·중단 기준·증적 보호를 설계해야 한다. 핵심 시스템과 공급자가 시험에 포함될 때는 사전 조율과 독립성, 이해상충 통제가 중요하며, 발견사항의 재시험까지 폐쇄해야 한다.

마. 경영진 책임과 현장 권한

경영진은 복원력 목표와 위험을 승인하되, 실무자가 위기 상황에서 서비스를 격리하고 복구를 시작할 실질 권한을 갖도록 해야 한다. 연락 체계, 의사결정 대체자, 승인 한도, 고객·감독기관 통지 책임을 훈련하여 조직 구조의 병목을 줄인다.

바. 데이터 품질과 자동화

자산 목록, 공급자 등록부, 사고 분류, 테스트 기록이 부정확하면 자동화는 잘못된 보고를 빠르게 만들 뿐이다. 데이터 소유자·갱신 시점·검증 규칙을 정의하고 원천 시스템과 증적 저장소 사이의 계보를 관리해야 한다. 자동화된 판단은 사람의 승인과 설명 가능한 예외 절차를 대체하지 않도록 한다.

사. 한국 금융기관과 기술기업의 대응

EU 금융시장과 거래하는 한국 기관은 법적 적용성뿐 아니라 유럽 고객의 위탁·보안·사고통지 요구를 계약 단위로 파악해야 한다. 공급자로 참여하는 기술기업은 보안증적, 서비스 의존성, 하위위탁, 사고 통지와 복구지원 능력을 제품 운영의 일부로 관리한다. 기술사는 규제 대응을 단기 문서화로 끝내지 않고, 고객 서비스 수준과 기술 부채·운영비용의 균형을 반영한 단계적 로드맵으로 제시해야 한다.

참고자료

한 줄 요약: DORA는 금융기관의 ICT 위험·사고·테스트·제3자 의존성을 업무서비스 중심으로 통합해, 장애가 발생해도 핵심 기능을 지속·복구하고 생태계 복원력을 입증하도록 하는 EU 규정이다.