ITの非専門家の立場にたってみれば、「ITの人は“エンタープライズ・アーキテクチャ（EA）などという言葉を使って話しをややこしくしているが、最初から“全社の共通設計”と言ってくれればよいのに」と思われているかもしれないのである。
このような用語の意味の相違による潜在的問題のもうひとつの例として「リスク」という言葉の使い方がある。
典型的なIT技術者にとって、「リスク」とはシステム障害やデータ漏えいなどの重大な問題の潜在的原因というニュアンスが強いのではないだろうか？ しかし、内部統制の世界では「リスク」という言葉のニュアンスはもっと広い。
たとえば、「機器購買において相見積もりをしていないことがある」というのはリスクの例である。必要以上に高い買い物をすることで業務への投資の効率性が損なわれる可能性があるからだ。内部統制の世界では、リスク＝潜在的問題点と翻訳した方が適切であるかもしれない（ちなみに、こちらの定義の方が英語の“risk”の元々の意味には近い）。
重要なポイントは、このような基本的な用語、すなわち、基本的な概念について、内部統制確立プロジェクトに関与する関係者がすべて共通の理解をしておくことだ。内部統制のプロジェクトメンバーのバックグラウンドは、IT、企業会計、会計監査、業務、経営など多様だ。そのため、言葉の理解の不足がコミュニケーションの不足を招き、内部統制プロジェクトの全体的効率性を損なうことだけは避けるべきだ。
たとえば、監査系のメンバーが他者の立場で、（自分にとっては）自明に思われる用語もかみくだいて説明するように、IT系のメンバーも部外者にとっては意味不明であるかもしれないIT系の用語を明確に説明することが必要になるだろう。
内部統制という言葉を使用する場合に留意すべきもうひとつの点は、内部統制においてITは（重要ではあるが）副次的な存在であるということだ。
内部統制の中心にあるのは業務であり、ITではない。内部統制のプロセスの中で、ITに関連したサブセット部分を、特に「IT内部統制」と呼ぶ。IT関係者だけで話をしている時には、内部統制＝IT内部統制としてしまってよいかもしれないが、他部門の人間が会話に参加している場合には、内部統制とIT内部統制を明確に区別すべきだろう。
さらに、IT内部統制は、IT業務処理統制とIT全般統制に分かれる点にも注意が必要だ。IT業務処理統制とは、アプリケーション（業務プログラム）における内部統制である。本来的には、アプリケーションの仕様の一部であり、アプリケーションの要件定義を行う利用部門の責任範囲となる（とはいえ、現実的にはIT部門の開発組織が関与せざるを得ないが……）。
一方、IT全般統制とは、アプリケーションが有効に稼動するための基盤／環境作りのための内部統制である。要するに、IT管理部門が日常的に行っている戦略立案、企画、開発、運用、保守などのプロセスにおける問題点の相互チェック機能である。IT部門がJ-SOX法対応を行う場合には、このIT全般統制が作業の中心となることが多い。
ここでもまたIT業務処理統制とIT全般統制という用語の使い分けに注意が必要だ。文脈から明らかな場合は別として、今話している内部統制が、IT業務処理統制のことを言っているのかIT全般統制のことを言っているのかに混乱があるような場合には、有意義な議論を行うことはむずかしくなるだろう。
