IAM Policy to enforce KMS encryption when

It looks like this is not possible via an IAM policy condition. You can create a detective control via AWS Config using the CLOUDWATCH_LOG_GROUP_ENCRYPTED AWS managed rule.

IAM policy conditions for CloudWatch log groups are conspicuously limited, indeed, but if your immediate issue is that your admins are creating log groups manually and neglecting to enable encryption, you might be able to work around that by forcing them to use CloudFormation to create the log groups. You could point them to a CloudFormation template that requires specifying a KMS key ARN for the log group (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-loggroup.html). With the AllowedPattern property for the KMS key ARN parameter in the CloudFormation template, you could even limit them to specific KMS keys or keys in a specific AWS account, by filtering by the account ID included in the key ARN.

In the IAM policy (or permissions boundary or SCP) for CloudWatch Logs, you could deny the CreateLogGroup action if the global condition key aws:CalledViaLast did not equal cloudformation.amazonaws.com. That would ensure your admins could only create log groups via CloudFormation and not directly from the console or CLI. In your IAM policy for CloudFormation, you would deny the CreateStack, UpdateStack, and CreateChangeSet actions when the cloudformation:ResourceTypes condition key matched AWS::Logs::LogGroup but the cloudformation:TemplateUrl condition key would not match (StringNotLike) the URL of your CloudFormation template. You would store your template in an S3 bucket where you have write access but your admins only have read access.

This should ensure your admins could only create new log groups with the CloudFormation template that you control, and that template would require specifying a KMS key ARN. The admins would still be able to use their own CloudFormation templates to manage all other types of resources.