ERP와 SaaS 중 무엇이 더 좋은지를 먼저 묻기보다 어느 시스템이 기준정보와 최종원장을 책임지고, 다른 도구는 어느 단계까지 처리할지 정해야 합니다. ERP는 여러 업무와 원장을 통합하는 범위를 가리키고, SaaS는 소프트웨어를 제공·운영하는 방식에 가깝습니다. ERP도 SaaS 방식으로 제공될 수 있으므로 둘은 완전한 반대말이 아닙니다.
선택의 핵심은 회사 규모가 아니라 시스템 경계입니다. 현재 원장이 안정적이고 자금 수집이나 증빙 확인처럼 좁은 병목만 있다면 기존 원장을 유지한 채 보조도구를 연결할 수 있습니다. 반대로 구매·재고·생산·매출·원가·회계가 서로 다른 기준정보로 움직여 결산 때마다 다시 맞춘다면 통합 범위를 넓힐 이유가 있습니다. 어느 경우든 원천 거래에서 최종 전표까지의 식별자, 대사 책임, 권한, 변경기록과 종료 시 데이터 회수가 확인되지 않으면 도입을 승인하기 어렵습니다.
“근거 확인일: 2026년 7월 15일 아래의 시스템 경계표, fit-gap 분류와 파일럿 기준은 회사가 선택안을 비교하기 위한 실무 모델입니다. 법정 공통 임계값이나 특정 제품의 지원 범위를 뜻하지 않습니다.”*읽기 전 참고사항
먼저 답: ERP 중심과 기존 원장+보조도구 중 무엇을 고르나요?
| 현재 상태 | 우선 검토할 구조 | 선택 논리 |
|---|---|---|
| 구매·재고·생산·매출·원가·회계의 기준정보와 마감이 서로 강하게 연결됨 | 통합원장 중심 | 같은 거래를 여러 시스템에서 다시 분류하는 구조를 줄이고 원가·재고·매출·회계 마감의 기준을 연결 |
| 기존 회계원장과 결산은 안정적이고, 자금 수집·증빙·승인 등 일부 업무만 병목 | 기존 원장+보조도구 | 최종원장을 바꾸지 않고 좁은 병목만 개선하되 전표 반영과 대사 책임을 명확히 함 |
| 법인·사업부별 원장은 유지해야 하지만 연결·통합 보고가 필요 | 원장 유지+별도 통합 계층 | 법인별 법정 장부와 연결 조정·환산·내부거래 제거의 책임을 분리 |
| 기준정보 소유자, 최종원장, 인터페이스 책임 또는 데이터 추출 범위를 정할 수 없음 | 선택 보류 | 시스템을 추가할수록 중복 원장과 미해결 차이가 늘어날 가능성이 큼 |
소규모면 SaaS, 복잡하면 ERP라는 문장만으로는 부족합니다. 거래가 적어도 승인 분리와 규제 보고가 중요한 회사가 있고, 거래가 많아도 단순·반복 거래를 안정적으로 처리하는 회사가 있습니다. 선택안은 인원 수보다 업무 간 결합도, 마감 결과, 통제 위험과 데이터 이동 가능성으로 비교해야 합니다.
1. 최종원장과 보조도구의 경계를 먼저 그립니다
시스템 경계표에는 데이터마다 권위 있는 기록, 생성·수정 권한, 최종 반영 위치, 대사 방법을 적습니다. 한 데이터가 여러 곳에 복제될 수는 있지만, 어느 기록을 기준으로 판단할지는 하나로 정해야 합니다.
| 데이터 영역 | 권위 있는 기록을 정할 때 확인할 것 | 보조도구가 할 수 있는 범위 | 최종 확인 |
|---|---|---|---|
| 계정과목·법인·부서·프로젝트·세무코드 | 코드 ID, 유효기간, 생성·변경 승인자, 폐기·대체 코드 | 승인된 기준정보를 읽거나 후보를 요청 | 원장 기준정보 버전과 일치 여부 |
| 은행·카드·세금계산서 등 원천 거래 | 외부 거래 ID, 거래시각, 금액, 취소·정정 연결키 | 수집, 형식 검증, 중복 후보 표시 | 원천 제공자료의 건수·금액과 대사 |
| 증빙·업무 목적·결재 | 문서 ID, 제출자, 검토·승인자, 승인 당시 값 | 자료 보완, 결재 진행, 예외 목록 생성 | 승인본과 전표 반영값의 일치 |
| 매입·매출·재고·고정자산 등 보조부 | 거래별 잔액, 평가·상각·정산 규칙, 마감 상태 | 해당 영역의 계산과 전표 후보 생성 | 보조부 합계와 총계정원장 통제계정 대사 |
| 분개·총계정원장 | 전표번호, 회계기간, 차변·대변, 작성·검토·승인과 마감 상태 | 승인된 전표 요청 전송 | 최종 원장의 유효 전표와 연결 |
| 경영 보고·자금 전망 | 원장 확정값, 운영 데이터, 조정·가정 버전 | 분석·시나리오 작성 | 원장값과 관리 조정의 연결표 |
여기서 원장 소유는 서버를 직접 보유한다는 뜻만이 아닙니다. 회사가 데이터 정의와 사용 권한을 통제하고, 계약 종료 뒤에도 거래·전표·첨부·승인·변경기록을 필요한 형식으로 회수해 재현할 수 있어야 한다는 뜻입니다.
경계표에서 다음 질문에 답하지 못하면 후보 평가를 멈추는 편이 좋습니다.
- 계정과목이나 거래처 코드가 두 시스템에서 다를 때 어느 쪽이 우선인가?
- 보조도구에서 분류가 바뀌면 이미 승인된 전표도 바뀌는가?
- 원천 거래 ID와 최종 전표번호를 양방향으로 찾을 수 있는가?
- 마감 뒤 수정은 누가 어느 시스템에서 승인하는가?
- 보조부 합계와 총계정원장 통제계정의 차이는 누가 언제 해소하는가?
2. 기능 목록 대신 fit-gap을 증거로 분류합니다
fit-gap은 후보가 요구사항을 지원하는지 확인하고, 차이가 있다면 설정·연동·업무 변경·개발 중 무엇으로 메울지 정하는 작업입니다. 모든 차이를 개발 요청으로 보내면 초기 도입은 가능해 보여도 업그레이드와 회귀시험 부담이 커질 수 있습니다.
| 분류 | 의미 | 확인할 증거 | 의사결정 |
|---|---|---|---|
| 표준 적합 | 기본 흐름으로 요구사항 충족 | 실제 시나리오 시연, 입력·출력·권한 결과 | 채택 후보 |
| 설정 차이 | 코드·규칙·결재선·기간 설정으로 충족 | 설정 목록, 변경 권한, 버전·시험 방법 | 운영 책임자를 정한 뒤 채택 |
| 인터페이스 차이 | 다른 시스템이 데이터를 소유하므로 연결 필요 | 필드 명세, 식별자, 오류·재처리·대사 설계 | 연동 책임과 운영비 확인 |
| 업무 차이 | 기존 관행을 바꾸면 표준 흐름 사용 가능 | 정책 근거, 사용자 영향, 승인된 변경안 | 통제를 약화하지 않는지 검토 |
| 맞춤 개발 | 표준·설정으로 충족 불가 | 개발 범위, 회귀시험, 업그레이드 영향, 철회 방법 | 생애주기 부담까지 승인 |
| 치명적 미충족 | 법정 보고·핵심 통제·최종원장·데이터 회수 요구를 충족하지 못함 | 대체 통제도 시험할 수 없음 | 점수와 관계없이 제외 |
요구사항은 기능이 있다가 아니라 재현 가능한 시나리오로 씁니다. 예를 들어 권한 관리 가능 대신 다음처럼 적습니다.
“지급 요청자는 자신의 요청을 승인할 수 없고, 승인 후 금액·계좌·거래처가 바뀌면 기존 승인값과 변경값, 사유, 수정자와 재승인 결과가 남아야 한다.”
각 요구사항에는 중요도, 현재 처리량, 기대 결과, 시험 데이터, 합격 조건과 책임자를 붙입니다. 치명적 미충족을 먼저 제외하고 난 뒤에만 편의성이나 구현 공수를 비교해야 합니다. 총점이 높아도 최종원장 소유권이나 데이터 추출이 불명확하면 선택할 수 없습니다.
3. API와 배치 중 무엇이 낫나요?
API가 항상 배치보다 정확한 것은 아닙니다. 필요한 처리시점, 거래량, 상대 시스템의 상태 확인 방식과 장애 복구 조건에 따라 선택합니다.
| 연결 방식 | 적합한 상황 | 주요 실패 형태 | 필요한 통제 |
|---|---|---|---|
| 화면 직접 입력 | 소량·비정형 예외를 사람이 판단 | 이중 입력, 입력자 편차, 승인 우회 | 입력·검토 권한 분리, 변경기록, 전표번호 연결 |
| 표준 파일 | 일정 주기의 다수 거래를 같은 형식으로 전달 | 잘못된 템플릿, 일부 행 실패, 중복 업로드 | 파일·스키마 버전, 파일 ID, 행별 결과, 합계 대사 |
| 배치 인터페이스 | 마감시각이 정해진 반복 처리 | 배치 지연, 중간 실패, 재시작 중복 | 실행 ID, 처리구간, 재시작 위치, 성공·반려·보류 분리 |
| 요청·응답 API | 건별 상태를 빠르게 확인해야 함 | 타임아웃 뒤 실제 성공, 순서 역전, 반복 요청 | 멱등 키, 상태 조회, 재시도 한도, 요청·응답 기록 |
인터페이스 명세에는 필드 이름만 적지 않습니다. 다음 항목이 있어야 운영 중 차이를 해소할 수 있습니다.
- 원천 거래 ID, 법인 ID, 문서·결재 버전과 최종 전표번호
- 통화·부호·금액 단위·회계기간·기준시각과 시간대
- 계정·부서·프로젝트·거래처 매핑 버전과 유효일
- 필수값, 허용값, 중복 판단키와 취소·정정 연결 규칙
- 접수·성공·반려·보류 상태, 오류 코드와 책임자
- 재시도, 부분 실패, 순서 역전, 중단·재개와 되돌림 규칙
- 스키마 변경 통지기간, 병행 지원기간과 회귀시험 범위
건수와 금액은 어떤 식으로 대사하나요?
한 실행 안의 상태를 겹치지 않게 정의하면 다음 등식으로 완전성을 확인할 수 있습니다.
수신 건수 = 원장 반영 건수 + 반려 건수 + 보류 건수
수신 금액 = 원장 반영 금액 + 반려 금액 + 보류 금액
원장 미설명 차이
= 인터페이스상 원장 반영 금액
- 총계정원장 반영 금액
- 승인된 기간차이·환율차이·정정차이대사표에는 차이를 0으로 보이게 상계하기보다 건별 절대금액, 원인, 책임자, 해소기한을 남깁니다. 성공 상태인데 최종 전표번호가 없거나, 같은 멱등 키에 유효 전표가 둘 이상 연결되면 실행을 완료로 닫지 않습니다.
| 책임 영역 | 최소 책임 |
|---|---|
| 원천 데이터 담당 | 추출 범위·기준시각·건수·금액 확인, 원천 정정 통지 |
| 인터페이스 운영 담당 | 실행·오류·재시도·스키마 변경 관리 |
| 회계 담당 | 매핑·귀속기간·승인·전표 반영과 보조부-원장 대사 |
| 시스템 관리자 | 계정·권한·설정 변경과 기술 로그 관리 |
| 외부 제공자 | 계약된 가용성·장애 통지·데이터 반환·기술지원 이행 |
외부 제공자가 전송 성공을 확인해도 장부 반영의 완전성까지 대신 책임지는 것은 아닙니다. 회사는 원천과 최종원장을 연결하는 대사를 수행하고 미해결 차이를 승인된 절차로 종결해야 합니다.
4. 권한 분리와 감사기록은 시연으로 확인합니다
권한표에는 메뉴 열람 여부보다 생성, 수정, 승인, 전송, 마감, 기준정보 변경, 사용자·권한 관리를 나눠 적습니다. 자금 집행이나 최종 전표에 영향을 주는 고위험 조합은 한 사용자가 처음부터 끝까지 수행하지 못하도록 하거나, 소규모 조직이라면 별도 사후 검토 같은 보완 통제를 둡니다.
| 역할 | 허용할 업무 | 분리하거나 별도 검토할 업무 |
|---|---|---|
| 거래 작성자 | 원천자료 연결, 초안 작성, 보완 | 자신의 지급·고위험 전표 최종 승인 |
| 검토·승인자 | 증빙·계정·금액·지급조건 검토와 승인 | 근거 없는 일괄 승인, 자신의 기준정보 변경 승인 |
| 회계 확정자 | 승인된 전표 검토, 원장 반영, 대사 | 사용자 권한의 단독 부여와 삭제 |
| 기준정보 관리자 | 코드 생성·변경 요청 처리 | 변경 요청·승인·운영 반영의 전 과정 단독 수행 |
| 시스템 관리자 | 계정·인터페이스·운영 설정 관리 | 회계 판단과 지급·전표의 단독 확정 |
감사기록은 단순 로그인 이력을 넘어 회계 결과를 재현해야 합니다. 최소한 사건 유형, 발생시각, 사용자·서비스 계정, 대상 데이터, 변경 전후 값, 처리 결과, 원천 거래 ID·결재번호·전표번호가 연결돼야 합니다. 로그 열람·추출 권한과 보존기간, 시간 동기화, 실패 시 대응도 확인합니다.
NIST SP 800-53 Rev. 5와 Release 5.2.0은 AC-5에서 업무 분리, AU-3에서 사건의 종류·시각·위치·발생 주체·결과·관련 주체를 포함하는 감사기록, CM-3에서 변경의 제안·검토·승인·구현·시험·기록 통제를 제시합니다. 이는 국내 회계처리 규칙이 아니라 정보시스템 통제를 설계할 때 참고하는 공식 기준입니다.
외부감사법 제8조의 적용을 받는 회사는 회계정보의 식별·측정·분류·기록·보고, 오류 통제와 수정, 정기 점검·조정, 장부 관리와 위·변조 방지, 업무 분장과 책임을 내부회계관리규정에 포함해야 합니다. 모든 법인에 같은 시스템 구현을 요구하는 조항은 아니므로 회사의 적용 여부와 내부회계 범위를 별도로 확인해야 합니다.
5. 데이터 이관은 잔액만 옮기는 일이 아닙니다
이관 범위는 전환 뒤 수행할 업무와 조회 의무로 정합니다. 과거 전체를 신규 전표로 다시 생성하면 중복 장부가 생길 수 있고, 잔액만 옮기면 미결 거래와 변경 근거가 끊길 수 있습니다.
| 이관 묶음 | 확인할 내용 | 검증 방법 |
|---|---|---|
| 기준정보 | 계정·거래처·법인·부서·프로젝트·세무코드·통화·사용자·권한, 유효기간 | 중복·미매핑·폐기 코드와 승인된 매핑표 확인 |
| 기초잔액 | 계정·보조부·통화별 전환일 잔액 | 구 시스템 마감잔액과 차·대변, 보조부-원장 대사 |
| 미결 항목 | 미수·미지급·선급·선수·재고·고정자산·미완료 결재 | 후속 수금·지급·상각·승인 시나리오 시험 |
| 거래 이력 | 문서·전표·취소·정정·연결 ID와 기간 | 건수·금액·표본 역추적 |
| 증빙·승인 | 첨부, 결재 버전, 수정사유, 승인자·시각 | 표본 거래를 원천에서 최종 전표까지 재현 |
| 운영 기록 | 인터페이스 실행, 오류·재처리, 기준정보·권한 변경 | 필요한 기간과 형식으로 조회·추출 시험 |
이관 전후에는 최소한 다음 등식을 검증합니다.
구 시스템 마감잔액 + 승인된 전환 조정 = 신 시스템 기초잔액
이관 대상 건수 = 성공 건수 + 반려 건수 + 제외 승인 건수차이가 있다면 기타 조정으로 묶지 않고 항목별 근거, 승인자와 재처리 결과를 남깁니다. 원화 합계만 맞추지 말고 법인·계정·보조부·통화·거래처 등 실제 마감 단위로 나눠 확인합니다.
6. 계약 전에 종료 가능성을 시험합니다
데이터를 화면에서 내려받을 수 있다는 답만으로 종료 가능성을 확인할 수 없습니다. 계약 전에 표본 데이터를 실제로 추출하고, 다른 환경에서 열어 식별자와 관계를 복원할 수 있는지 봐야 합니다.
| 종료·추출 항목 | 계약·시험에서 확인할 질문 |
|---|---|
| 데이터 범위 | 기준정보, 거래, 전표, 보조부, 첨부, 승인, 변경·오류 기록이 모두 포함되는가? |
| 형식·명세 | 공개되거나 충분히 문서화된 형식인가? 필드 정의·코드표·관계키가 제공되는가? |
| 추출 방법 | 전체·증분 추출, API·파일, 대용량 처리와 재시도 방법은 무엇인가? |
| 시점 | 계약 중·종료 통지 뒤·종료 뒤 각각 언제까지 접근하고 추출할 수 있는가? |
| 검증 | 건수·금액·첨부 수·해시 또는 체크섬을 비교할 수 있는가? |
| 지원과 부담 | 추출·변환·이관 지원 범위, 소요기간과 추가 부담은 무엇인가? |
| 삭제·보존 | 반환 확인 뒤 제공자 보관본의 삭제·법정 보존·백업 처리 증거는 무엇인가? |
| 사업 연속성 | 종료·장애 때 읽기 전용 조회, 미결 거래 처리, 대체 절차와 복구 목표가 있는가? |
영국 정부의 Make better use of data 지침은 공급자 계약에서 모든 데이터에 대한 접근과 데이터의 종료·갱신 조건을 정하고, 기반 데이터베이스의 개방형 형식 또는 표준을 따르는 API로 반환할 것을 요구합니다. 또한 개별 데이터의 접근·갱신을 보여 주는 감사추적을 고려하도록 합니다. 이 지침은 영국 정부 조달 기준이므로 국내 민간기업의 법적 의무로 확대하지 않고, 계약·종료 실사를 위한 참고 원칙으로 사용합니다.
영국 정부 Open Standards Principles는 상호운용성과 데이터 이전, 공급자 종속 완화, 프로젝트 시작 시점의 종료·이관 비용 추정을 강조합니다. 특정 표준을 쓴다는 주장보다 회사가 필요한 데이터 관계를 실제로 추출·복원할 수 있는지 시험하는 것이 중요합니다.
7. 파일럿은 정상 시연보다 실패 복구를 검증합니다
파일럿 범위는 가장 쉬운 거래만 고르지 않습니다. 대표 거래, 고액·고위험 거래, 취소·정정, 승인 후 변경, 일부 실패, 중복 요청, 마감 후 수정과 데이터 추출을 포함해야 합니다.
시작 전에 고정할 기준선
- 현재 월마감 완료일과 주요 선행 업무별 지연
- 거래·증빙 건수, 재작업 건수와 시간
- 미해결 대사 항목과 차이 절대금액
- 승인 후 수정, 권한 충돌과 변경기록 누락
- 데이터 추출에 걸리는 시간과 누락 항목
합격 조건 예시
아래 수치는 업계 기준이 아니라 고위험 회계처리 파일럿에서 회사가 채택할 수 있는 내부 합격 조건의 예입니다.
- 핵심 기준정보의 미매핑 항목이 없고 모든 변경에 요청·승인·유효일이 연결됨
- 수신 건수·금액과 성공·반려·보류 합계의 미설명 차이가 0
- 원장 반영 성공 건마다 원천 거래 ID·승인 버전·최종 전표번호가 연결됨
- 중복 유효 전표와 미승인 원장 반영이 0
- 고위험 역할 충돌, 감사기록 누락과 미해결 최우선 결함이 0
- 종료 시험에서 합의한 데이터·첨부·승인·기록을 정해진 형식과 시간 안에 추출하고 표본을 복원함
- 되돌림·재처리·장애 대응 시나리오가 예상 결과와 일치함
중단 조건 예시
- 기준정보나 최종원장의 권위 있는 시스템을 합의할 수 없음
- 같은 거래가 두 번 원장에 반영되거나 원천과 원장 차이를 설명할 수 없음
- 승인 뒤 핵심 값이 기록 없이 바뀌거나 작성자가 자신의 고위험 거래를 우회 승인할 수 있음
- 오류·재시도·설정 변경의 사용자·시각·전후 값·결과를 재현할 수 없음
- 전체 데이터 추출에서 거래 ID, 전표 관계, 첨부 또는 승인 기록이 빠짐
- 치명적 오류가 발생했을 때 전환 전 상태로 되돌리거나 미결 거래를 안전하게 처리할 방법이 없음
처리시간이 줄어도 통제 결함이 생기면 파일럿을 통과시키지 않습니다. 반대로 통제는 충족했지만 속도 개선이 작다면 투자경제성 판단에서 다시 검토할 수 있습니다. 시스템 적합성과 투자수익률은 같은 결론이 아닙니다.
가상 사례: 기존 원장을 유지하고 보조도구만 연결하는 경우
법인 A는 기존 총계정원장으로 월마감을 안정적으로 수행하지만, 6개 계좌와 4개 카드의 거래 수집·증빙 확인이 늦어 일일 자금표가 지연됩니다. 재고·원가·매출 인식은 현재 원장과 보조부에서 문제가 없으므로 전체 원장을 교체하는 것은 파일럿 목적에 비해 범위가 큽니다.
경계는 다음처럼 정할 수 있습니다.
| 영역 | 정한 기준 |
|---|---|
| 원천 거래 | 은행·카드 거래 ID와 취소 연결키를 수정하지 않고 보존 |
| 기준정보 | 계정·부서·프로젝트는 기존 원장의 승인된 코드와 유효기간 사용 |
| 보조도구 | 거래 수집, 증빙 연결, 분류 후보와 승인 대기 목록까지 담당 |
| 최종원장 | 승인된 전표만 받아 전표번호를 반환하고 마감·정정은 기존 원장 정책 적용 |
| 대사 | 실행별 건수·금액·상태와 전표번호를 매일 확인, 월말 통제계정과 재대사 |
| 종료 | 거래·증빙·승인·매핑·전송 결과를 관계키와 함께 전체 추출 시험 |
한 달 파일럿에서 1,000건, 120,000,000원을 수신했고 원장 반영 970건·116,000,000원, 반려 20건·2,500,000원, 보류 10건·1,500,000원이었다고 가정해 보겠습니다.
1,000건 = 970건 + 20건 + 10건
120,000,000원
= 116,000,000원 + 2,500,000원 + 1,500,000원산술 합계가 맞는 것만으로는 부족합니다. 970건 모두 최종 전표번호와 연결되고 중복 전표가 없어야 하며, 반려·보류 30건에는 원인·책임자·해소기한이 있어야 합니다. 월말에는 원장 반영액과 통제계정을 대사하고 승인된 기간차이를 제외한 미설명 차이가 0인지 확인합니다.
이 사례의 결론은 항상 보조도구가 낫다가 아닙니다. 현재 최종원장과 보조부가 안정적이고 병목이 좁기 때문에 경계를 유지한 것입니다. 구매·재고·생산·원가와 회계가 서로 다른 기준으로 움직여 대사 차이가 반복된다면 같은 회사라도 통합원장 범위를 다시 검토해야 합니다.
최종 선택표
| 결정 질문 | 통과 증거 | 통과하지 못할 때 |
|---|---|---|
| 최종원장과 기준정보의 소유자가 명확한가? | 영역별 권위 시스템·생성·수정·승인·대사 책임표 | 구조 선택 보류 |
| 핵심 요구사항의 fit-gap이 검증됐는가? | 시나리오별 실제 결과, 치명적 미충족 0 | 후보 제외 또는 범위 재정의 |
| 연동 실패와 재처리를 통제할 수 있는가? | 식별자·상태·멱등·재시도·건수·금액 대사 시험 | 운영 전환 금지 |
| 권한과 변경기록을 재현할 수 있는가? | 역할 충돌 시험, 전후 값·승인·결과 로그 | 보완 통제 재설계 |
| 이관 뒤 장부와 미결 거래가 이어지는가? | 잔액·보조부·거래·첨부·승인 대사 | 이관 범위·매핑 수정 |
| 계약 종료 뒤 데이터를 회수할 수 있는가? | 전체 추출, 명세, 표본 복원과 종료 소요시간 | 계약·후보 재검토 |
| 파일럿 실패 때 중단·복구할 수 있는가? | 중단 기준, 되돌림, 미결 처리와 책임자 | 전면 전환 금지 |
ERP와 SaaS의 이름보다 이 일곱 질문의 증거가 중요합니다. 최종원장·기준정보·원천데이터의 경계를 먼저 정하고, fit-gap과 인터페이스를 실제 거래로 시험하며, 권한·기록·이관·종료까지 통과한 구조만 운영 후보로 남겨야 합니다.
공식 참고 자료
- 국가법령정보센터, 외부감사법 제8조: 적용 회사의 회계정보 처리, 오류 통제·수정, 내부검증, 장부 관리와 업무 분장·책임 범위를 확인했습니다.
- NIST, SP 800-53 Rev. 5 및 Release 5.2.0: AC-5 업무 분리, AU-3 감사기록 내용, CM-3 변경 통제를 정보시스템 통제 참고 기준으로 확인했습니다.
- UK Government, Make better use of data: 데이터 생애주기, 감사추적, 계약상 데이터 접근, 종료·갱신 조건과 개방형 형식·API 반환 원칙을 확인했습니다.
- UK Government, Open Standards Principles: 상호운용성, 데이터 이전, 공급자 종속 완화와 프로젝트 시작 시 종료·이관 비용 검토 원칙을 확인했습니다.
