QA 감사관이 모든 기기 담당자가 가장 두려워하는 질문을 던집니다:

“이 HPLC의 제어 시스템을 백업으로부터 성공적으로 복원(restore)했던 가장 최근 기록을 보여주십시오.”

백업 로그가 아닙니다. 백업 일정이 아닙니다. 바로 ’복원’입니다. 회의실은 침묵에 휩싸입니다. 대부분의 팀은 수 테라바이트에 달하는 백업 증적은 제출할 수 있어도, 정작 실험대 위에 놓인 바로 그 기기를 대상으로 문서화되고 성공적으로 수행된 복원 기록은 단 한 건도 제시하지 못하기 때문입니다.

여기에 두 번째 질문이 이어집니다: “그리고 오늘 밤 저 제어용 PC가 고장 난다면, IQ/OQ(설치/운전 적격성평가)를 처음부터 다시 수행하지 않고 어떻게 검증된 상태(validated state)로 되돌릴 수 있습니까?”

이것이 바로 GxP 환경에서 백업이 직면한 실질적인 문제이며, 장비가 중요할수록 그 난이도는 극적으로 높아집니다. 생산 공정을 직접 운영하는 장비들—바이오리액터 PLC, 클린룸 HVAC 컨트롤러, 충전 라인(filling line), 동결건조기(lyophilizer), 안정성 챔버(stability chamber)—은 가장 엄격하게 보안 강화(hardened)되어 있습니다. 벤더가 봉인한 전용 OS 빌드, 비활성화된 USB 포트, 인터넷 차단, 인바운드 네트워크 트래픽 불허, 그리고 소프트웨어의 어떠한 사소한 변경도 변경 관리(Change Control) 대상으로 간주하는 밸리데이션 동결(validation freeze) 상태가 적용되어 있기 때문입니다.

이러한 제약 조건 하에서는 기존의 전형적인 백업 전략이 완전히 무너집니다. 범용 백업 에이전트의 설치 자체가 이미 밸리데이션된 시스템을 변경하는 행위입니다. 풀(pull) 기반의 백업은 보안 팀이 결코 허용하지 않을 네트워크 접근성을 요구합니다. 독점적인 기기 데이터 포맷을 단순 파일 단위로 복사하는 방식은 감사 추적(Audit Trail)을 누락시켜 규제 증적으로서의 가치를 상실하게 만듭니다. 그리고 이 중 어느 것도 감사관이 던진 실제 질문에 답하지 못합니다.

관점의 전환이 필요합니다: 하든드(hardened) 장비의 백업은 단순한 파일 복사가 아닙니다. ’밸리데이션된 상태의 복구(validated-state recovery)’입니다.

하든드(Hardened) 장비가 기존 백업 방식을 무력화하는 이유

이 맥락에서 “하든드(보안 강화)“란 여러 계층의 엄격한 제약이 중첩되어 있음을 의미하며, 각각의 제약은 일반적인 백업 툴이 전제하는 기본 가정을 무너뜨립니다:

제약 사항 기존 백업 방식이 무력화되는 이유 실제로 작동하는 해결책
잠금 처리 및 벤더 고정 OS (Windows Embedded, 잠긴 Linux 이미지 등) 범용 에이전트 설치는 밸리데이션된 상태의 변경이며, 재밸리데이션(Revalidation)을 유발함 에이전트리스(Agentless) 기법; 벤더가 검증(적격성평가)한 유틸리티만 사용
인터넷 차단; 엄격한 아웃바운드 규칙이 적용된 격리 VLAN 외부 백업 서버가 내부로 접근하여 데이터를 가져오는 풀(pull) 방식 불가 아웃바운드 전용 푸시(outbound-only push); MFA 기반 배스천/점프 호스트; 단방향 데이터 다이오드
잠기거나 비활성화된 USB 포트; 클린룸 갱의(Gowning) 물류 문제 수동 미디어 교체는 비실용적이며 통제되지 않는 위험 발생 정기 유지보수 기간 중 골든 이미지(Golden image) 캡처; 통제된 보관 체계를 갖춘 듀얼 산업용 CF/SD 미디어
독점적 기기 데이터 포맷 (CDS, 스펙트럼, Historian 저장소) 파일 단위 복사 시 메타데이터와 감사 추적(Audit Trail)이 은밀히 누락됨 — “진본 사본(True copy)” 불충족 벤더 네이티브 익스포트/API; 네이티브 데이터베이스 덤프; 데이터, 메타데이터, 감사 추적을 동기식으로 동시 캡처
패치 적용 불가능한 시스템 (밸리데이션 동결로 OS 업데이트 차단) 제조 현장에 영구적으로 노출된 보안 취약 장비 물리적 또는 논리적 데이터 다이오드 격리; 일체의 인바운드 네트워크 경로 차단
시스템 전체가 변경 관리(Change Control) 하에 운영됨 백업 프로세스 자체도 밸리데이션된 상태에 대한 변경으로 취급됨 컴퓨터화 시스템 밸리데이션(CSV)의 일환으로 백업/복원 적격성평가 수행; 승인된 SOP에 따라 실행; 모든 변경을 변경 관리 절차로 처리

이 문제를 더욱 시급하게 만드는 역설은 가장 엄격하게 하든드된 장비가 대개 가장 크리티컬(critical)한 장비라는 점입니다. 안정성 챔버 컨트롤러나 바이오리액터 PLC는 장시간의 다운타임을 결코 감당할 수 없습니다. 이들이 생성하는 데이터는 대체 불가능하며 시간에 따라 인덱싱되기 때문입니다. 랜섬웨어 감염, 디스크 장애, 데이터베이스 손상, 혹은 15년 된 노후 산업용 PC의 고장 등 모든 사고는 결국 동일한 질문으로 귀결됩니다: 정확히 밸리데이션된 상태를, 신속하게, 규제 증적을 갖추어 재구축할 수 있는가?

진정한 목표: 파일이 아닌 ’밸리데이션된 상태’의 복원

하든드 GxP 시스템에서 “백업”은 일반적인 서버보다 훨씬 더 많은 계층을 책임져야 합니다. 손실 시 겪게 되는 위험도와 복구 난이도 순으로 백업 스택을 정리하면 다음과 같습니다:

  1. 설정(Configuration), 레시피(Recipes), 분석법(Methods) — PLC 프로그램, HMI 프로젝트, SCADA 설정, 기기 분석법, 설정값(Setpoints), 알람 설정, 펌웨어 버전. 이는 일반적으로 OS 자체보다 더 중요합니다. PLC 프로그램이 유실된 50만 달러짜리 장비는 비싼 고철 덩어리에 불과합니다. 기계가 제 역할을 수행하도록 만드는 핵심은 바로 그 프로그램이기 때문입니다.
  2. 시스템 이미지(System images) — 산업용 PC의 베어메탈(bare-metal) 또는 섹터 단위 디스크 이미지: OS, 드라이버, 애플리케이션, 로컬 데이터베이스, 설정값 일체. 검증된 정상 이미지(known-good image)를 복원하면 전체 밸리데이션을 처음부터 다시 수행하지 않고도 시스템을 적격성평가 완료(qualified) 상태로 되돌릴 수 있습니다.
  3. 데이터베이스(Databases) — 특정 시점 복구(Point-in-time recovery)를 위한 네이티브 덤프 및 트랜잭션 로그. 데이터베이스 백업은 단순 디스크 이미지보다 훨씬 정밀한 복구 시점 세분성(granularity)을 제공합니다.
  4. 펌웨어 및 소프트웨어 버전 — 아카이빙되고 버전 관리되며, 해당 밸리데이션 상태(IQ/OQ/PQ 기록서, 변경 관리 문서)와 직접 연계된 패키지.
  5. 감사 추적(Audit trails) 및 메타데이터 — 규제 컴플라이언스 계층. 백업에 감사 추적이 포함되어 있지 않다면, 복원된 데이터는 규제 준수 맥락(compliance context)을 상실한 셈입니다.

핵심 운영 원칙은 **골든 복구 패키지(Golden Recovery Package)**입니다. 밸리데이션된 각 장비마다 모든 계층—OS 빌드, 애플리케이션 버전, PLC 펌웨어 및 프로그램 리비전, HMI 프로젝트 버전, 데이터베이스 스키마 버전, 드라이버 패키지, 설정 버전, 이들을 뒷받침하는 IQ/OQ 참조 번호 및 변경 관리 번호, 그리고 가장 최근 성공한 복원 테스트 일자—을 단일 문서화된 번들로 유지 관리해야 합니다. CSV/CSA(컴퓨터화 시스템 밸리데이션 / 컴퓨터화 시스템 보증) 관점에서 이는 단순한 파일 복사를 넘어 **검증된 밸리데이션 상태(known validated state)**를 고스란히 보존한다는 점에서 매우 강력합니다.

Equipment: Bioreactor-07                              
                                                      
GOLDEN RECOVERY PACKAGE                               
──────────────────────────────────────────────────────
OS:            Windows 11 IoT, Build XXXXX            
Application:   Vendor X v5.4.2                        
PLC:           Siemens firmware X, Program v17        
HMI:           Project v8                             
Database:      SQL schema v4                          
Drivers:       Driver package X                       
Configuration: Config v12                             
Validation:    IQ/OQ reference, Change control #      
Recovery:      Last successful restore test 2026-08-14

하든드 시스템에 적합한 4가지 백업 아키텍처

에이전트 설치, 오픈 포트, 수동 미디어 반입이 모두 불가능한 상황에서 실제로 기능하는 것으로 입증된 네 가지 패턴이 있습니다. 이들은 상호 보완적이므로, 신뢰성 있는 백업 프로그램이라면 대부분을 병행 운영합니다:

백업 아키텍처 구현 메커니즘 GxP 무결성 및 복구 초점 최적 적용 대상
에이전트리스 네트워크 섀도잉 (Agentless network shadowing) 읽기 전용 서비스 계정을 통해 격리된 VLAN 상에서 SFTP/SCP/SMB3로 데이터베이스 덤프(Oracle, SQL Server, PostgreSQL) 또는 정적 설정 파일을 수집 밸리데이션된 소프트웨어 스택에 전혀 영향을 주지 않음(Zero footprint) — 하든드 엔드포인트에 대한 소프트웨어 적격성평가 오버헤드 없음 실험실 워크스테이션, 크로마토그래피 데이터 시스템(CDS), 환경 모니터링 시스템(EMS)
에어갭(Air-gapped) 골든 이미지 베이스라인 정기 유지보수 기간 동안 쓰기 방지(write-blocked) 미디어에 주기적으로 베어메탈 또는 섹터 단위 디스크 복제(Clonezilla, Veeam Agent, Macrium Reflect 등) 수행 전체 CSV / C&Q(시운전 및 적격성평가)를 재수행하지 않고 신속한 재해 복구(RTO) 달성 네트워크 인터페이스가 없는 독립형(Standalone), 레거시 또는 임베디드 OS 기기
PLC / 펌웨어 프로그램 볼팅 (Vaulting) 산업용 형상 관리 도구(VersionDog, Copadata, Rockwell FactoryTalk AssetCentre 등)를 통한 컨트롤러 로직, 펌웨어 리비전, 레시피 파라미터의 자동 폴링 개별 렁(rung) 또는 레지스터 블록 단위까지의 변경 추적; 현장에서 승인되지 않은 수동 파라미터 드리프트(drift) 감지 클린룸 HVAC 컨트롤러, 충전 라인, 바이오리액터 PLC, 동결건조기
불변(Immutable) 객체 스토리지 타깃 시계열 원시 데이터 및 감사 로그를 WORM(Write-Once, Read-Many) 스토리지(S3 Object Lock, 규제 준수 SAN/NAS)로 직접 스트리밍 부인 방지(non-repudiation) 보장; 랜섬웨어 감염이나 인가되지 않은 내부 수정 및 삭제 원천 차단 배치 공정 Historian, 원시 분석 스펙트럼, 감사 추적 저장소

전체 데이터 경로는 푸시(push)만 가능한 장비에서 출발하여, 역방향 접근이 불가능한 전송 계층을 거쳐, 수정이 불가능한 저장소로 전달되며, 백업 도메인이 통째로 장악되더라도 살아남는 최종 오프라인 사본으로 완결됩니다:

Hardened equipment (no agents, no inbound traffic)                        
        │  outbound-only push (SFTP/SCP/SMB3) or scheduled media capture  
        ▼                                                                 
Bastion / data diode ──── one-way, monitored, MFA-protected               
        │                                                                 
        ▼                                                                 
Encrypted backup repository (AES-256 at rest, TLS 1.3 in transit)         
        │                                                                 
        ├───────────────────────────────┐                                 
        ▼                               ▼                                 
Immutable/WORM copy               Offline / air-gapped copy               
(retention-locked)                (rotated media, safe storage)           
        │                                                                 
        ▼                                                                 
Restore testing ──► qualification/sandbox environment, evidence documented

백업 격리(Backup isolation)는 해당 전략이 랜섬웨어 공격 속에서 살아남을 수 있는지를 결정짓는 핵심 개념입니다. 백업 서버가 운영(Production) 환경과 동일한 보안 도메인에 속해 있다면, 단 하나의 관리자 계정만 탈취당해도 두 환경이 동시에 장악됩니다. 현대적 백업 아키텍처는 정해진 보존 기간 동안 백업 사본을 불변(immutable) 상태로 잠급니다. 관리자라 할지라도, 혹은 탈취당한 관리자 계정이라 할지라도 백업 이력을 삭제할 수 없어야 합니다. 불변성은 또한 강력한 데이터 무결성 통제 항목입니다: 백업이 변경 불가능한 사본임을 보장함으로써 ALCOA+ 원칙의 *원본성(Original)*과 영속성(Enduring) 측면을 완벽히 보호합니다.

백업의 규제 타당성을 입증하는 6가지 통제 항목

다음은 백업 작업을 신뢰할 수 있는 규제 감사 증적으로 전환시키는 통제 항목들이며, 이들의 부재는 곧바로 실사 지적사항(Observation / Form 483)으로 이어집니다:

  • 감사 추적(Audit Trail) 분리는 절대 금지됩니다. 메타데이터와 시스템 감사 추적을 동시에 캡처하지 않고 원시 기기 데이터만 단독으로 백업해서는 안 됩니다. 기기가 독점적인 내부 포맷으로 로그를 저장하는 경우, 추출 유틸리티는 두 구성 요소를 동기식으로 함께 수집해야 합니다. 21 CFR Part 11의 “진본 사본(True copy, 정확하고 완전한 기록 사본 — § 11.10(b))” 규정과 FDA의 데이터 무결성 기대치는 데이터 뿐만 아니라 데이터에 맥락을 부여하는 감사 추적이 함께 수반됨을 의미합니다. 감사 추적이 누락된 복원 데이터는 규제 컴플라이언스 지위를 상실합니다.
  • 이중 서명 기반의 암호학적 검증 (Dual-signoff cryptographic verification). 백업 생성 즉시, 그리고 목적지 수신 시점에 SHA-256 해시 생성을 자동화합니다. 백업 실행 로그는 시스템 관리자(System Administration)와 품질보증부서(Quality Assurance) 모두에 의해 검토되고 주기적으로 서명(Sign-off)되어야 합니다. 해시값은 백업 파일과 물리적으로 분리되어 보관되며, 복원 시 검증을 통해 은밀한 데이터 손상(silent corruption)을 사전에 감지합니다.
  • 패치 불가능한 장비를 위한 데이터 다이오드 격리. OS 패치를 적용할 수 없는 제조 현장의 노후 레거시 기기는 어떠한 시스템과도 양방향 네트워크 경로를 공유해서는 안 됩니다. 물리적 하드웨어 데이터 다이오드(Data Diode) 또는 엄격하게 구성된 단방향(아웃바운드 전용) 방화벽 규칙을 통해 백업 패킷을 중앙 저장소로 푸시하되, 외부로부터의 수평 이동(lateral movement) 트래픽에 장비가 노출되지 않도록 해야 합니다.
  • 모든 구간의 암호화 (Encryption everywhere). 전송 중 암호화(TLS)와 저장 시 암호화(AES-256)를 적용하고, 이상적으로는 고객 관리형 키(CMK)를 사용해야 합니다. 이동식 미디어의 경우 암호화와 더불어 관리 연속성(Chain of custody), 라벨링, 물리적 접근 통제가 수반되어야 합니다.
  • 복원 및 삭제에 대한 직무 분리(Segregation of Duties). 복원 및 삭제 작업에는 다자 승인(Multi-party approval) 체계를 적용하여, 단 한 명의 관리자도 규제 대상 백업을 임의로 변경하거나 파기할 수 없도록 통제합니다. 모든 백업 관련 작업은 감사 추적에 기록되며, 접근 권한은 정기적으로 검토되어야 합니다.
  • 기록 보존 일정과 일치하는 백업 보존 기간. 백업 보존 기간은 IT 부서의 편의 기준이 아니라, 규제 기준의 기록 보존 일정(대개 해당 의약품의 유효기간 + 1년 이상)과 엄격히 일치해야 합니다.

거버넌스: 백업 프로세스 자체가 밸리데이션된 GxP 통제 항목이다

GAMP 5 지침에 따르면 백업 및 복원 메커니즘은 컴퓨터화 시스템의 일부이며, 따라서 밸리데이션 대상에 포함됩니다. 이는 다음과 같은 구체적인 요구사항을 의미합니다:

  • 백업 소프트웨어의 적격성평가(Qualification). 하든드 환경 내에서의 백업 도구 및 샌드박스 환경으로의 복원 경로에 대해 문서화된 IQ/OQ가 수행되어야 합니다.
  • 백업 설정의 변경은 변경 관리(Change Control) 절차를 거침. 하든드 시스템에 대한 패치, 새로운 백업 도구 버전 적용, 백업 주기 변경 등은 모두 공식 변경 관리 절차를 거쳐야 하며, 이후 백업 프로세스에 대한 회귀 테스트(regression testing)가 수반되어야 합니다.
  • 정기 검토(Periodic Review) 시 백업 로그 검토. 이탈(Deviation)과 실패는 명확히 플래그 지정되고 조치되어야 합니다. 백업 로그 검토는 IT 모니터링 콘솔에만 머무르는 것이 아니라, 시스템의 공식 정기 검토 주기에 포함되어야 합니다.
  • 복원 테스트가 유일한 증명이다. 바로 이 지점에서 대부분의 기업이 취약성을 드러냅니다. 한 번도 복원해보지 않은 백업은 단지 ’백업 가설(backup hypothesis)’에 불과합니다. 감사관들은 비생산 적격성평가(샌드박스) 환경에서 수행된 정기 복원 챌린지 테스트의 문서화된 증적을 일상적으로 요구합니다. 그리고 해당 테스트는 전체 체인을 모두 거쳐야 합니다:
BACKUP
   ▼
Backup integrity verification (hashes match source)
   ▼
Restore to recovery/qualification environment
   ▼
Verify configuration
   ▼
Verify application
   ▼
Verify data
   ▼
Verify audit trail
   ▼
Verify interfaces
   ▼
Functional test
   ▼
Document evidence (QA sign-off)

분기별로, 혹은 데이터 관리 계획서(Data Management Plan)에 정의된 위험 기반 주기에 따라 모든 테스트를 문서화해야 하며, 불일치 사항과 시정 조치까지 빠짐없이 기록되어야 합니다. 문제를 조기에 발견해 낸 복원 훈련은 성공입니다. 하지만 동일한 문제가 실제 재해 상황에서 발견된다면 그것은 제품 회수(recall)로 이어집니다.

계층화 전략: 중요도(Criticality)에 따른 복구 심도 매칭

모든 기기가 동일한 수준의 심층 보호를 필요로 하는 것은 아닙니다. GxP 중요도(Criticality)에 따라 장비를 분류하고, 그 분류에 따라 아키텍처와 목표 복구 시점(RPO) / 목표 복구 시간(RTO)을 결정해야 합니다:

장비 중요도 백업 접근 방식
낮음 (Low) 설정(Configuration) + 정기 백업
중간 (Medium) 설정 + 데이터베이스 + 시스템 이미지
높음 (High) 이미지 + 데이터베이스 + 설정 + 불변(Immutable) 백업
중요 (Critical) 위 항목 전체 + 오프라인/에어갭 사본 + 예비 하드웨어(Spare hardware)
핵심 미션 (Mission-critical) 위 항목 전체 + 실증 복원 테스트 + 대기/이중화 시스템(Standby/redundant system)

RPO와 RTO는 문서화된 비즈니스/공정 위험 평가(Risk Assessment)에서 도출됩니다. 아래 수치들은 템플릿이 아니라 일반적인 형태를 예시한 것입니다:

                    RPO          RTO
Critical EMS       15 min       1 hour
Manufacturing       1 hour      4 hours
Lab instrument     24 hours    24 hours
Noncritical        24 hours    72 hours

대부분의 계획에서 간과하는 두 가지 추가 요소가 있습니다. 첫째는 **예비 하드웨어(Spare hardware)**입니다. 15년 된 노후 산업용 PC의 하드웨어를 구할 수 없다면 아무리 완벽한 백업이라도 무용지물입니다. 복구 이미지를 사전에 구성된 예비 산업용 PC와 페어링해 두고 정기적으로 재구축 과정을 실증해야 합니다. 둘째는 **장비 자체의 전력 복원력(Power resilience)**입니다. 안정성 챔버, 저온 저장소, 환경 모니터링 시스템은 문서화된 절체 테스트(switchover testing)를 거쳐 밸리데이션된 UPS/비상 발전기/ATS(자동절체스위치) 보호를 받아야 합니다. 정전으로 인해 발생한 데이터 공백(data gap)은 어떠한 사후 백업으로도 되돌릴 수 없는 치명적인 데이터 무결성 실패입니다.

대시보드를 넘어서: 장비 복구 기록서(Equipment Recovery Record)

이 모든 것을 가장 유용하게 바라보는 관점은 단순한 “백업 작업(jobs)“이 아니라, 각 장비별로 단일 표준 객체(canonical object)를 구축하는 것입니다. 바로 모든 백업 아티팩트를 해당 시스템의 밸리데이션 상태와 직접 결합하는 **장비 복구 기록서(Equipment Recovery Record)**입니다:

Equipment                     
   │                          
   ├── Validated configuration
   ├── Software versions      
   ├── Firmware versions      
   ├── PLC program            
   ├── HMI project            
   ├── Database               
   ├── Backup versions        
   ├── Recovery procedures    
   ├── Spare hardware         
   ├── RPO                    
   ├── RTO                    
   ├── Last restore test      
   ├── Validation status      
   └── Change controls

이것이 바로 백업을 단순 IT 인프라 기능에서 **GxP 장비 복구성 관리(GxP equipment recoverability management)**로 격상시키는 열쇠입니다. 이는 마스터 데이터 관리(MDM) 및 지식 그래프(Knowledge Graph) 아키텍처가 해결하도록 설계된 전형적인 과제이기도 합니다. 각 장비 기록은 마스터 데이터 엔티티가 되며, 백업 버전, 밸리데이션 상태, 변경 관리 문서, 복원 증적은 해당 엔티티의 속성 및 관계가 됩니다. 데이터가 이러한 구조로 구축되면, AI 에이전트는 현재 모든 품질 조직을 곤혹스럽게 만드는 다음과 같은 질문에 즉각 답할 수 있습니다:

“바이오리액터 17호기의 제어 PC가 고장 나면 어떻게 됩니까?”

…그리고 해당 기록서로부터 종합적인 복구 대응 보고서를 도출합니다: 장비 중요도, RTO/RPO, 최근 검증된 설정 버전, 최근 성공한 백업 타임스탬프, 최근 복원 테스트 일자, 예비 하드웨어 보유 여부, 전체 아티팩트 체크리스트(OS 이미지, PLC 프로그램, HMI 프로젝트, 데이터베이스, 드라이버, 설정, 라이선스 정보), 그리고 현재 PLC 펌웨어가 골든 형상과 불일치함과 같은 미결 이슈까지 일목요연하게 파악합니다. 마지막 줄이야말로 이 아키텍처의 진정한 진가입니다: 재해가 발생한 후가 아니라 발생하기 전에 현재 상태가 밸리데이션된 상태에서 이탈(drift)했음을 시스템이 사전에 인지할 수 있기 때문입니다.

기존의 백업 대시보드는 작업이 실행되었는지만 알려줍니다. 반면 장비 복구 기록서는 밸리데이션된 상태가 실제로 복원 가능한지를 알려줍니다 — 그리고 이것이야말로 규제 실사에서 검증하는 유일한 핵심 질문입니다.

요약 및 제언

하든드 GxP 장비의 백업은 단순한 IT 유틸리티가 아니라 밸리데이션된 통제 항목(validated control)입니다. 만약 우리가 내일 당장 귀사의 제조 시설에 들어가 점검을 수행한다면, 다음의 항목들은 타협할 수 없는 필수 요건이 될 것입니다:

  1. 증적이 동반된 실증 복원 테스트. “백업을 보유하고 있습니다”는 답이 될 수 없습니다. 각 핵심 장비의 문서화되고 성공적인 최신 복원 기록만이 답이 됩니다. QA 서명이 완료된 적격성평가 환경에서의 분기별 복원 훈련을 수립하십시오.
  2. 불변(Immutable) 및 격리된 백업 사본. WORM/객체 잠금 스토리지와 물리적 또는 논리적 에어갭 사본을 확보하십시오 — 랜섬웨어가 도달할 수 있는 백업은 백업이 아닙니다.
  3. 소스 코드처럼 버전 관리되는 형상. PLC 프로그램, HMI 프로젝트, 레시피, 기기 분석법을 형상 관리 하에 두고 변경 관리와 연계하십시오. 이를 통해 1월 5일에 검증된 형상과 오늘의 형상 사이에 무엇이 달라졌는지에 즉시 답변할 수 있어야 합니다.
  4. 모든 백업 세트에 감사 추적(Audit Trail) 포함. 데이터, 메타데이터, 감사 추적은 반드시 함께 움직여야 합니다. 그렇지 않으면 복원된 데이터는 규제 컴플라이언스 맥락을 잃게 됩니다.
  5. 장비별 복구 기록서(Equipment Recovery Record) 구축. 밸리데이션된 설정, 소프트웨어 버전, RPO/RTO, 예비 하드웨어, 최신 복원 테스트 기록을 단일 표준의 쿼리 가능한 객체로 관리하십시오. 이는 복구 가능성을 단순한 로그 폴더에서 ’명확히 답할 수 있는 질문’으로 전환하는 기반이 됩니다.

감사관은 백업이 정상 실행되었는지를 묻지 않습니다. 밸리데이션된 상태가 제시간에, 명확한 증적과 함께 재구축될 수 있는지를 묻습니다. 이 질문에 답할 수 있도록 아키텍처를 설계한다면, 규제 실사는 자연스럽게 통과할 것입니다.

관련 글: 마스터 데이터를 특정 벤더 플랫폼에 종속시키지 말아야 하는 이유 · 환각 엣지 없는 지식 그래프 구축 · QMSR과 AI 시대: 에이전틱 컴플라이언스